Re: [PATCH 0/5] uart updates
On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following - Make the Make the suspend/resume functions depend on CONFIG_PM_SLEEP - Fix the serial omap probe's error handling - Make he context_loss_cnt signed so that error handling is possible. After fixing Kevin's comment's, If can add some testing updates it be nice. like : boot tested or any other tests done on xxx boards. -- Thanks, Govindraj.R Shubhrajyoti D (5): omap-serial :Make the suspend/resume functions depend on CONFIG_PM_SLEEP. omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME omap-serial: Fix the error handling in the omap_serial probe ARM : OMAP : serial : Make context_loss_cnt signed OMAP : serial : Check for error in get_context_loss_count arch/arm/plat-omap/include/plat/omap-serial.h | 2 +- drivers/tty/serial/omap-serial.c | 41 2 files changed, 28 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-serial in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] coupled cpuidle state support
On 12/21/2011 01:09 AM, Colin Cross wrote: On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the cpus cannot be independently powered down, either due to sequencing restrictions (on Tegra 2, cpu 0 must be the last to power down), or due to HW bugs (on OMAP4460, a cpu powering up will corrupt the gic state unless the other cpu runs a work around). Each cpu has a power state that it can enter without coordinating with the other cpu (usually Wait For Interrupt, or WFI), and one or more coupled power states that affect blocks shared between the cpus (L2 cache, interrupt controller, and sometimes the whole SoC). Entering a coupled power state must be tightly controlled on both cpus. The easiest solution to implementing coupled cpu power states is to hotplug all but one cpu whenever possible, usually using a cpufreq governor that looks at cpu load to determine when to enable the secondary cpus. This causes problems, as hotplug is an expensive operation, so the number of hotplug transitions must be minimized, leading to very slow response to loads, often on the order of seconds. This patch series implements an alternative solution, where each cpu will wait in the WFI state until all cpus are ready to enter a coupled state, at which point the coupled state function will be called on all cpus at approximately the same time. Once all cpus are ready to enter idle, they are woken by an smp cross call. At this point, there is a chance that one of the cpus will find work to do, and choose not to enter suspend. A final pass is needed to guarantee that all cpus will call the power state enter function at the same time. During this pass, each cpu will increment the ready counter, and continue once the ready counter matches the number of online coupled cpus. If any cpu exits idle, the other cpus will decrement their counter and retry. To use coupled cpuidle states, a cpuidle driver must: Set struct cpuidle_device.coupled_cpus to the mask of all coupled cpus, usually the same as cpu_possible_mask if all cpus are part of the same cluster. The coupled_cpus mask must be set in the struct cpuidle_device for each cpu. Set struct cpuidle_device.safe_state to a state that is not a coupled state. This is usually WFI. Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each state that affects multiple cpus. Provide a struct cpuidle_state.enter function for each state that affects multiple cpus. This function is guaranteed to be called on all cpus at approximately the same time. The driver should ensure that the cpus all abort together if any cpu tries to abort once the function is called. This series was functionally tested on v3.0, but has only been compile-tested on v3.2 after the removal of per-cpu state fields. Hi Colin, this patchset could be interesting to resolve in a generic way the cpu dependencies. What is the status of this patchset ? Did you have the opportunity to measure the power consumption with and without this patchset ? Thanks -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro:http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap-serial: Fix the error handling in the omap_serial probe
On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
The patch does the following
- The pm_runtime_disable is called in the remove not in the error
case of probe.The patch calls the pm_runtime_disable in the error
case.
- The up is not freed in the error path. Fix the memory leak by calling
kfree in the error path.
- Also the iounmap is not called fix the same by calling iounmap in the
error case of probe and remove .
- Make the name of the error tags more meaningful.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/tty/serial/omap-serial.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 1c24269..8c6f137 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1369,14 +1369,14 @@ static int serial_omap_probe(struct platform_device
*pdev)
dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
if (!dma_rx) {
- ret = -EINVAL;
- goto err;
+ ret = -ENXIO;
+ goto do_release_region;
}
dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
if (!dma_tx) {
- ret = -EINVAL;
- goto err;
+ ret = -ENXIO;
+ goto do_release_region;
}
up = kzalloc(sizeof(*up), GFP_KERNEL);
@@ -1403,7 +1403,7 @@ static int serial_omap_probe(struct platform_device
*pdev)
dev_err(pdev-dev, failed to get alias/pdev id, errno %d\n,
up-port.line);
ret = -ENODEV;
- goto err;
+ goto err_port_line;
}
sprintf(up-name, OMAP UART%d, up-port.line);
@@ -1412,7 +1412,7 @@ static int serial_omap_probe(struct platform_device
*pdev)
if (!up-port.membase) {
dev_err(pdev-dev, can't ioremap UART\n);
ret = -ENOMEM;
- goto err;
+ goto err_ioremap;
}
up-port.flags = omap_up_info-flags;
@@ -1458,16 +1458,22 @@ static int serial_omap_probe(struct platform_device
*pdev)
ret = uart_add_one_port(serial_omap_reg, up-port);
if (ret != 0)
- goto do_release_region;
+ goto err_add_port;
pm_runtime_put(pdev-dev);
platform_set_drvdata(pdev, up);
return 0;
-err:
- dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
- pdev-id, __func__, ret);
+
+err_add_port:
+ pm_runtime_disable(pdev-dev);
+ iounmap(up-port.membase);
+err_ioremap:
+err_port_line:
+ kfree(up);
do_release_region:
release_mem_region(mem-start, resource_size(mem));
+ dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
+ pdev-id, __func__, ret);
return ret;
}
@@ -1476,6 +1482,7 @@ static int serial_omap_remove(struct platform_device
*dev)
struct uart_omap_port *up = platform_get_drvdata(dev);
if (up) {
+ iounmap(up-port.membase);
you can build omap-serial as module insmod and rmmod
the module and test this patch.
This can be done on zoom board which uses a non-omap uart
as console.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] OMAP : serial : Check for error in get_context_loss_count
On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
In serial_omap_runtime_resume in case of errors returned by
get_context_loss_count print a warning and do a restore.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/tty/serial/omap-serial.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 8c6f137..e1c1a0f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1602,10 +1602,16 @@ static int serial_omap_runtime_resume(struct device
*dev)
if (up) {
if (pdata-get_context_loss_count) {
- u32 loss_cnt = pdata-get_context_loss_count(dev);
+ int loss_cnt = pdata-get_context_loss_count(dev);
Looks ok to me,
Can you ensure off mode is tested with this patch.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM : OMAP : serial : Make context_loss_cnt signed
On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
get_context_loss_count returns an int however it is stored in
unsigned integer context_loss_cnt . This patch tries to make
context_loss_cnt int. So that in case of errors(which may be negative)
the value is not interpreted wrongly.
This change should be part [1] patch of itself
[1]:
[PATCH 5/5] OMAP : serial : Check for error in get_context_loss_count
--
Thanks,
Govindraj.R
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..b7fb6dc 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -128,7 +128,7 @@ struct uart_omap_port {
unsigned char msr_saved_flags;
char name[20];
unsigned long port_activity;
- u32 context_loss_cnt;
+ int context_loss_cnt;
u32 errata;
u8 wakeups_enabled;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-serial in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
So I re-iterate that we need to have solution to this problem. ... I don't want to be a pain, but it seems to me that this dicussion didn't reach a full conclussion? I think it was left with the open options being: 1) Leave the L2/outer cache enabled in the bootloader (not ideal and may cause problems with future devices) 2) Turn the L2/outer cache on for OMAP3 later in the kernel boot when the device is known Is there any concensus? Cheers, Joe Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/31] Clean up amba/primecell bus support
This patch set cleans up the AMBA/Primecell bus support. Contained within this set are: 1. Patches 1-5 - Allocation APIs It seems several places in the kernel want to allocate and register amba_device structures. Let's make this official, and common code. So we introduce amba_device_alloc(), amba_device_add(), and amba_device_put() APIs, which provide the necessary support safely for this. Convert the DT, ux500, Integrator/AP and mxs code to use these APIs rather than their private version. 2. Patches 6-17 - NO_IRQ cleanup Making IRQ number 0 mean 'no irq' for the AMBA drivers and bus layer. We get rid of NO_IRQ initializers in this across various platforms, and make the bus layer warn if '-1' is passed in a device as an IRQ. This prevents new occurances of NO_IRQ initializers for this bus type going by unspotted. 3. Patches 18-31 - static initializers Provide a standardized set of initializers for statically declared AMBA devices. We provide two - one for the simpler APB devices, and one for AHB devices. The major difference between these two is the setting of the DMA mask - APB peripherals do not have DMA capability themselves. While updating (3), I came across new additions in Spear3xx and the Samsung directories which added AMBA devices, which are declared globally. The Spear3xx devices are used in other files, so that's fine. Samsung devices don't seem to be - and that needs fixing (did someone not run checkpatch or sparse on these changes?) Please send fixes. Acks for these patches are welcome. arch/arm/mach-bcmring/core.c | 23 +- arch/arm/mach-ep93xx/core.c| 46 ++- arch/arm/mach-exynos/dma.c | 38 ++--- arch/arm/mach-integrator/core.c| 70 +++- arch/arm/mach-integrator/impd1.c |9 +-- arch/arm/mach-integrator/integrator_cp.c | 49 ++- arch/arm/mach-lpc32xx/phy3250.c| 32 +-- arch/arm/mach-mxs/devices.c|8 +- arch/arm/mach-mxs/devices/amba-duart.c |2 +- arch/arm/mach-netx/fb.c| 13 +--- arch/arm/mach-nomadik/board-nhk8815.c | 17 +--- arch/arm/mach-nomadik/cpu-8815.c |9 +-- arch/arm/mach-omap2/emu.c | 26 +-- arch/arm/mach-realview/core.h | 20 + arch/arm/mach-realview/realview_eb.c | 78 +- arch/arm/mach-realview/realview_pb1176.c | 78 +- arch/arm/mach-realview/realview_pb11mp.c | 78 +- arch/arm/mach-realview/realview_pba8.c | 78 +- arch/arm/mach-realview/realview_pbx.c | 78 +- arch/arm/mach-s5p64x0/dma.c| 22 + arch/arm/mach-s5pc100/dma.c| 38 ++--- arch/arm/mach-s5pv210/dma.c| 38 ++--- arch/arm/mach-spear3xx/spear300.c | 14 +--- arch/arm/mach-spear3xx/spear3xx.c | 27 +- arch/arm/mach-spear6xx/spear6xx.c | 10 +- arch/arm/mach-u300/core.c | 85 arch/arm/mach-ux500/devices-common.c | 13 +-- arch/arm/mach-versatile/core.c | 70 arch/arm/mach-versatile/core.h | 20 + arch/arm/mach-versatile/versatile_pb.c | 18 ++-- arch/arm/mach-vexpress/core.h | 17 arch/arm/mach-vexpress/ct-ca9x4.c |8 +- arch/arm/mach-vexpress/include/mach/ct-ca9x4.h |2 +- arch/arm/mach-vexpress/v2m.c | 20 ++-- drivers/amba/bus.c | 105 ++-- drivers/mmc/host/mmci.c|2 +- drivers/of/platform.c |6 +- include/linux/amba/bus.h | 36 38 files changed, 488 insertions(+), 815 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/31] ARM: amba: add amba_device allocation/add/put functions
Add functions to allocate and initialize AMBA device structures, and
add them to the Linux device manager. This allows us to kill this
type of operation from individual platforms, moving it to core code.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/amba/bus.c | 100 ++---
include/linux/amba/bus.h |3 +
2 files changed, 78 insertions(+), 25 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 54eaf96..82b65e1 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -497,38 +497,20 @@ static void amba_device_release(struct device *dev)
}
/**
- * amba_device_register - register an AMBA device
- * @dev: AMBA device to register
- * @parent: parent memory resource
+ * amba_device_add - add a previously allocated AMBA device structure
+ * @dev: AMBA device allocated by amba_device_alloc
+ * @parent: resource parent for this devices resources
*
- * Setup the AMBA device, reading the cell ID if present.
- * Claim the resource, and register the AMBA device with
- * the Linux device manager.
+ * Claim the resource, and read the device cell ID if not already
+ * initialized. Register the AMBA device with the Linux device
+ * manager.
*/
-int amba_device_register(struct amba_device *dev, struct resource *parent)
+int amba_device_add(struct amba_device *dev, struct resource *parent)
{
u32 size;
void __iomem *tmp;
int i, ret;
- device_initialize(dev-dev);
-
- /*
-* Copy from device_add
-*/
- if (dev-dev.init_name) {
- dev_set_name(dev-dev, %s, dev-dev.init_name);
- dev-dev.init_name = NULL;
- }
-
- dev-dev.release = amba_device_release;
- dev-dev.bus = amba_bustype;
- dev-dev.dma_mask = dev-dma_mask;
- dev-res.name = dev_name(dev-dev);
-
- if (!dev-dev.coherent_dma_mask dev-dma_mask)
- dev_warn(dev-dev, coherent dma mask is unset\n);
-
ret = request_resource(parent, dev-res);
if (ret)
goto err_out;
@@ -596,6 +578,74 @@ int amba_device_register(struct amba_device *dev, struct
resource *parent)
err_out:
return ret;
}
+EXPORT_SYMBOL_GPL(amba_device_add);
+
+static void amba_device_initialize(struct amba_device *dev, const char *name)
+{
+ device_initialize(dev-dev);
+ if (name)
+ dev_set_name(dev-dev, %s, name);
+ dev-dev.release = amba_device_release;
+ dev-dev.bus = amba_bustype;
+ dev-dev.dma_mask = dev-dma_mask;
+ dev-res.name = dev_name(dev-dev);
+}
+
+/**
+ * amba_device_alloc - allocate an AMBA device
+ * @name: sysfs name of the AMBA device
+ * @base: base of AMBA device
+ * @size: size of AMBA device
+ *
+ * Allocate and initialize an AMBA device structure. Returns %NULL
+ * on failure.
+ */
+struct amba_device *amba_device_alloc(const char *name, resource_size_t base,
+ size_t size)
+{
+ struct amba_device *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (dev) {
+ amba_device_initialize(dev, name);
+ dev-res.start = base;
+ dev-res.end = base + size - 1;
+ dev-res.flags = IORESOURCE_MEM;
+ }
+
+ return dev;
+}
+EXPORT_SYMBOL_GPL(amba_device_alloc);
+
+/**
+ * amba_device_register - register an AMBA device
+ * @dev: AMBA device to register
+ * @parent: parent memory resource
+ *
+ * Setup the AMBA device, reading the cell ID if present.
+ * Claim the resource, and register the AMBA device with
+ * the Linux device manager.
+ */
+int amba_device_register(struct amba_device *dev, struct resource *parent)
+{
+ amba_device_initialize(dev, dev-dev.init_name);
+ dev-dev.init_name = NULL;
+
+ if (!dev-dev.coherent_dma_mask dev-dma_mask)
+ dev_warn(dev-dev, coherent dma mask is unset\n);
+
+ return amba_device_add(dev, parent);
+}
+
+/**
+ * amba_device_put - put an AMBA device
+ * @dev: AMBA device to put
+ */
+void amba_device_put(struct amba_device *dev)
+{
+ put_device(dev-dev);
+}
+EXPORT_SYMBOL_GPL(amba_device_put);
/**
* amba_device_unregister - unregister an AMBA device
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 724c69c..e192962 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -60,6 +60,9 @@ extern struct bus_type amba_bustype;
int amba_driver_register(struct amba_driver *);
void amba_driver_unregister(struct amba_driver *);
+struct amba_device *amba_device_alloc(const char *, resource_size_t, size_t);
+void amba_device_put(struct amba_device *);
+int amba_device_add(struct amba_device *, struct resource *);
int amba_device_register(struct amba_device *, struct resource *);
void amba_device_unregister(struct amba_device *);
struct amba_device *amba_find_device(const
[PATCH 02/31] ARM: amba: of: convert to use amba_device_alloc
Convert DT code to use the new amba_device_alloc APIs. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/of/platform.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 63b3ec4..cae9477 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -253,7 +253,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node, if (!of_device_is_available(node)) return NULL; - dev = kzalloc(sizeof(*dev), GFP_KERNEL); + dev = amba_device_alloc(NULL, 0, 0); if (!dev) return NULL; @@ -283,14 +283,14 @@ static struct amba_device *of_amba_device_create(struct device_node *node, if (ret) goto err_free; - ret = amba_device_register(dev, iomem_resource); + ret = amba_device_add(dev, iomem_resource); if (ret) goto err_free; return dev; err_free: - kfree(dev); + amba_device_put(dev); return NULL; } #else /* CONFIG_ARM_AMBA */ -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/31] ARM: amba: ux500: convert to use amba_device_alloc
Convert ux500 to use the new amba_device_alloc APIs.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-ux500/devices-common.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-ux500/devices-common.c
b/arch/arm/mach-ux500/devices-common.c
index c563e54..e8c34fa 100644
--- a/arch/arm/mach-ux500/devices-common.c
+++ b/arch/arm/mach-ux500/devices-common.c
@@ -26,16 +26,10 @@ dbx500_add_amba_device(const char *name, resource_size_t
base,
struct amba_device *dev;
int ret;
- dev = kzalloc(sizeof *dev, GFP_KERNEL);
+ dev = amba_device_alloc(name, base, SZ_4K);
if (!dev)
return ERR_PTR(-ENOMEM);
- dev-dev.init_name = name;
-
- dev-res.start = base;
- dev-res.end = base + SZ_4K - 1;
- dev-res.flags = IORESOURCE_MEM;
-
dev-dma_mask = DMA_BIT_MASK(32);
dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -46,9 +40,9 @@ dbx500_add_amba_device(const char *name, resource_size_t base,
dev-dev.platform_data = pdata;
- ret = amba_device_register(dev, iomem_resource);
+ ret = amba_device_add(dev, iomem_resource);
if (ret) {
- kfree(dev);
+ amba_device_put(dev);
return ERR_PTR(ret);
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/31] ARM: amba: integrator: convert to use amba_device_alloc
Convert Integrator IM/PD-1 to use the new amba_device_alloc APIs.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-integrator/impd1.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index 8cbb75a..3e538da 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -401,24 +401,21 @@ static int impd1_probe(struct lm_device *dev)
pc_base = dev-resource.start + idev-offset;
- d = kzalloc(sizeof(struct amba_device), GFP_KERNEL);
+ d = amba_device_alloc(NULL, pc_base, SZ_4K);
if (!d)
continue;
dev_set_name(d-dev, lm%x:%5.5lx, dev-id, idev-offset
12);
d-dev.parent = dev-dev;
- d-res.start= dev-resource.start + idev-offset;
- d-res.end = d-res.start + SZ_4K - 1;
- d-res.flags= IORESOURCE_MEM;
d-irq[0] = dev-irq;
d-irq[1] = dev-irq;
d-periphid = idev-id;
d-dev.platform_data = idev-platform_data;
- ret = amba_device_register(d, dev-resource);
+ ret = amba_device_add(d, dev-resource);
if (ret) {
dev_err(d-dev, unable to register device: %d\n,
ret);
- kfree(d);
+ amba_device_put(d);
}
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/31] ARM: amba: mxs: convert to use amba_device_alloc
Convert MXS to use the new amba_device_alloc APIs.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-mxs/devices.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mxs/devices.c b/arch/arm/mach-mxs/devices.c
index fe3e847..052d8dd 100644
--- a/arch/arm/mach-mxs/devices.c
+++ b/arch/arm/mach-mxs/devices.c
@@ -77,16 +77,18 @@ struct platform_device *__init
mxs_add_platform_device_dmamask(
int __init mxs_add_amba_device(const struct amba_device *dev)
{
- struct amba_device *adev = kmalloc(sizeof(*adev), GFP_KERNEL);
+ struct amba_device *adev = amba_device_alloc(dev-init_name,
+ dev-res.start, resource_size(dev-res));
if (!adev) {
pr_err(%s: failed to allocate memory, __func__);
return -ENOMEM;
}
- *adev = *dev;
+ adev-irq[0] = dev-irq[0];
+ adev-irq[1] = dev-irq[1];
- return amba_device_register(adev, iomem_resource);
+ return amba_device_add(adev, iomem_resource);
}
struct device mxs_apbh_bus = {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/31] ARM: amba: make irq 0 invalid
Fix core bus and MMCI such that irq 0 means that there is no IRQ
attached.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/amba/bus.c |4 ++--
drivers/mmc/host/mmci.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 82b65e1..d15acbb 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -564,9 +564,9 @@ int amba_device_add(struct amba_device *dev, struct
resource *parent)
if (ret)
goto err_release;
- if (dev-irq[0] != NO_IRQ)
+ if (dev-irq[0] dev-irq[0] != NO_IRQ)
ret = device_create_file(dev-dev, dev_attr_irq0);
- if (ret == 0 dev-irq[1] != NO_IRQ)
+ if (ret == 0 dev-irq[1] dev-irq[1] != NO_IRQ)
ret = device_create_file(dev-dev, dev_attr_irq1);
if (ret == 0)
return ret;
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 0d955ff..304f2f9 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1325,7 +1325,7 @@ static int __devinit mmci_probe(struct amba_device *dev,
if (ret)
goto unmap;
- if (dev-irq[1] == NO_IRQ)
+ if (dev-irq[1] == NO_IRQ || !dev-irq[1])
host-singleirq = true;
else {
ret = request_irq(dev-irq[1], mmci_pio_irq, IRQF_SHARED,
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/31] ARM: amba: ux500: get rid of NO_IRQ
irq 0 now means no irq, so get rid of this unnecessary initializer. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-ux500/devices-common.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-ux500/devices-common.c b/arch/arm/mach-ux500/devices-common.c index e8c34fa..898a645 100644 --- a/arch/arm/mach-ux500/devices-common.c +++ b/arch/arm/mach-ux500/devices-common.c @@ -34,7 +34,6 @@ dbx500_add_amba_device(const char *name, resource_size_t base, dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); dev-irq[0] = irq; - dev-irq[1] = NO_IRQ; dev-periphid = periphid; -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/31] ARM: amba: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-ep93xx/core.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 24203f9..1a8397a 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -289,7 +289,7 @@ static struct amba_device uart1_device = {
.end= EP93XX_UART1_PHYS_BASE + 0x0fff,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_EP93XX_UART1, NO_IRQ },
+ .irq= { IRQ_EP93XX_UART1 },
.periphid = 0x00041010,
};
@@ -303,7 +303,7 @@ static struct amba_device uart2_device = {
.end= EP93XX_UART2_PHYS_BASE + 0x0fff,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_EP93XX_UART2, NO_IRQ },
+ .irq= { IRQ_EP93XX_UART2 },
.periphid = 0x00041010,
};
@@ -317,7 +317,7 @@ static struct amba_device uart3_device = {
.end= EP93XX_UART3_PHYS_BASE + 0x0fff,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_EP93XX_UART3, NO_IRQ },
+ .irq= { IRQ_EP93XX_UART3 },
.periphid = 0x00041010,
};
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/31] ARM: amba: samsung: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-exynos/dma.c |4 ++--
arch/arm/mach-s5p64x0/dma.c |2 +-
arch/arm/mach-s5pc100/dma.c |4 ++--
arch/arm/mach-s5pv210/dma.c |4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index b10fcd2..8d681bf 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -86,7 +86,7 @@ struct amba_device exynos4_device_pdma0 = {
.end = EXYNOS4_PA_PDMA0 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA0, NO_IRQ},
+ .irq = {IRQ_PDMA0},
.periphid = 0x00041330,
};
@@ -135,7 +135,7 @@ struct amba_device exynos4_device_pdma1 = {
.end = EXYNOS4_PA_PDMA1 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA1, NO_IRQ},
+ .irq = {IRQ_PDMA1},
.periphid = 0x00041330,
};
diff --git a/arch/arm/mach-s5p64x0/dma.c b/arch/arm/mach-s5p64x0/dma.c
index f820c07..99049aa 100644
--- a/arch/arm/mach-s5p64x0/dma.c
+++ b/arch/arm/mach-s5p64x0/dma.c
@@ -119,7 +119,7 @@ struct amba_device s5p64x0_device_pdma = {
.end = S5P64X0_PA_PDMA + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_DMA0, NO_IRQ},
+ .irq = {IRQ_DMA0},
.periphid = 0x00041330,
};
diff --git a/arch/arm/mach-s5pc100/dma.c b/arch/arm/mach-s5pc100/dma.c
index c841f4d3..ac08d7e 100644
--- a/arch/arm/mach-s5pc100/dma.c
+++ b/arch/arm/mach-s5pc100/dma.c
@@ -85,7 +85,7 @@ struct amba_device s5pc100_device_pdma0 = {
.end = S5PC100_PA_PDMA0 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA0, NO_IRQ},
+ .irq = {IRQ_PDMA0},
.periphid = 0x00041330,
};
@@ -139,7 +139,7 @@ struct amba_device s5pc100_device_pdma1 = {
.end = S5PC100_PA_PDMA1 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA1, NO_IRQ},
+ .irq = {IRQ_PDMA1},
.periphid = 0x00041330,
};
diff --git a/arch/arm/mach-s5pv210/dma.c b/arch/arm/mach-s5pv210/dma.c
index a6113e0..8602fa5 100644
--- a/arch/arm/mach-s5pv210/dma.c
+++ b/arch/arm/mach-s5pv210/dma.c
@@ -83,7 +83,7 @@ struct amba_device s5pv210_device_pdma0 = {
.end = S5PV210_PA_PDMA0 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA0, NO_IRQ},
+ .irq = {IRQ_PDMA0},
.periphid = 0x00041330,
};
@@ -139,7 +139,7 @@ struct amba_device s5pv210_device_pdma1 = {
.end = S5PV210_PA_PDMA1 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA1, NO_IRQ},
+ .irq = {IRQ_PDMA1},
.periphid = 0x00041330,
};
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/31] ARM: amba: integrator/realview/versatile/vexpress: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-integrator/core.c| 10 +++---
arch/arm/mach-integrator/integrator_cp.c |4 +-
arch/arm/mach-realview/realview_eb.c | 40
arch/arm/mach-realview/realview_pb1176.c | 40
arch/arm/mach-realview/realview_pb11mp.c | 40
arch/arm/mach-realview/realview_pba8.c | 40
arch/arm/mach-realview/realview_pbx.c | 40
arch/arm/mach-versatile/core.c | 34 ++--
arch/arm/mach-versatile/versatile_pb.c |8 ++--
arch/arm/mach-vexpress/include/mach/ct-ca9x4.h |2 +-
10 files changed, 129 insertions(+), 129 deletions(-)
diff --git a/arch/arm/mach-integrator/core.c b/arch/arm/mach-integrator/core.c
index 019f0ab..29baef9 100644
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@ -44,7 +44,7 @@ static struct amba_device rtc_device = {
.end= INTEGRATOR_RTC_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_RTCINT, NO_IRQ },
+ .irq= { IRQ_RTCINT },
};
static struct amba_device uart0_device = {
@@ -57,7 +57,7 @@ static struct amba_device uart0_device = {
.end= INTEGRATOR_UART0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_UARTINT0, NO_IRQ },
+ .irq= { IRQ_UARTINT0 },
};
static struct amba_device uart1_device = {
@@ -70,7 +70,7 @@ static struct amba_device uart1_device = {
.end= INTEGRATOR_UART1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_UARTINT1, NO_IRQ },
+ .irq= { IRQ_UARTINT1 },
};
static struct amba_device kmi0_device = {
@@ -82,7 +82,7 @@ static struct amba_device kmi0_device = {
.end= KMI0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_KMIINT0, NO_IRQ },
+ .irq= { IRQ_KMIINT0 },
};
static struct amba_device kmi1_device = {
@@ -94,7 +94,7 @@ static struct amba_device kmi1_device = {
.end= KMI1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_KMIINT1, NO_IRQ },
+ .irq= { IRQ_KMIINT1 },
};
static struct amba_device *amba_devs[] __initdata = {
diff --git a/arch/arm/mach-integrator/integrator_cp.c
b/arch/arm/mach-integrator/integrator_cp.c
index a8b6aa6..ecc08ed 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -370,7 +370,7 @@ static struct amba_device aaci_device = {
.end= INTEGRATOR_CP_AACI_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq= { IRQ_CP_AACIINT, NO_IRQ },
+ .irq= { IRQ_CP_AACIINT },
.periphid = 0,
};
@@ -437,7 +437,7 @@ static struct amba_device clcd_device = {
.flags = IORESOURCE_MEM,
},
.dma_mask = ~0,
- .irq= { IRQ_CP_CLCDCINT, NO_IRQ },
+ .irq= { IRQ_CP_CLCDCINT },
.periphid = 0,
};
diff --git a/arch/arm/mach-realview/realview_eb.c
b/arch/arm/mach-realview/realview_eb.c
index e629621..5c810e5 100644
--- a/arch/arm/mach-realview/realview_eb.c
+++ b/arch/arm/mach-realview/realview_eb.c
@@ -140,40 +140,40 @@ static struct pl022_ssp_controller ssp0_plat_data = {
/*
* These devices are connected via the core APB bridge
*/
-#define GPIO2_IRQ { IRQ_EB_GPIO2, NO_IRQ }
-#define GPIO3_IRQ { IRQ_EB_GPIO3, NO_IRQ }
+#define GPIO2_IRQ { IRQ_EB_GPIO2 }
+#define GPIO3_IRQ { IRQ_EB_GPIO3 }
-#define AACI_IRQ { IRQ_EB_AACI, NO_IRQ }
+#define AACI_IRQ { IRQ_EB_AACI }
#define MMCI0_IRQ { IRQ_EB_MMCI0A, IRQ_EB_MMCI0B }
-#define KMI0_IRQ { IRQ_EB_KMI0, NO_IRQ }
-#define KMI1_IRQ { IRQ_EB_KMI1, NO_IRQ }
+#define KMI0_IRQ { IRQ_EB_KMI0 }
+#define KMI1_IRQ { IRQ_EB_KMI1 }
/*
* These devices are connected directly to the multi-layer AHB switch
*/
-#define EB_SMC_IRQ { NO_IRQ, NO_IRQ }
-#define MPMC_IRQ { NO_IRQ, NO_IRQ }
-#define EB_CLCD_IRQ{ IRQ_EB_CLCD, NO_IRQ }
-#define DMAC_IRQ { IRQ_EB_DMA, NO_IRQ }
+#define EB_SMC_IRQ { }
+#define MPMC_IRQ { }
+#define EB_CLCD_IRQ{ IRQ_EB_CLCD }
+#define DMAC_IRQ { IRQ_EB_DMA }
/*
* These devices are connected via the core APB bridge
*/
-#define SCTL_IRQ { NO_IRQ, NO_IRQ }
-#define EB_WATCHDOG_IRQ{ IRQ_EB_WDOG, NO_IRQ }
-#define EB_GPIO0_IRQ { IRQ_EB_GPIO0, NO_IRQ }
-#define GPIO1_IRQ { IRQ_EB_GPIO1, NO_IRQ }
-#define EB_RTC_IRQ { IRQ_EB_RTC, NO_IRQ }
+#define SCTL_IRQ { }
[PATCH 11/31] ARM: amba: lpc32xx: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-lpc32xx/phy3250.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index bfee5b4..025eb21 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -161,7 +161,7 @@ static struct amba_device lpc32xx_clcd_device = {
.flags = IORESOURCE_MEM,
},
.dma_mask = ~0,
- .irq= {IRQ_LPC32XX_LCD, NO_IRQ},
+ .irq= {IRQ_LPC32XX_LCD},
};
/*
@@ -203,7 +203,7 @@ static struct amba_device lpc32xx_ssp0_device = {
.flags = IORESOURCE_MEM,
},
.dma_mask = ~0,
- .irq= {IRQ_LPC32XX_SSP0, NO_IRQ},
+ .irq= {IRQ_LPC32XX_SSP0},
};
/* AT25 driver registration */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/31] ARM: amba: mxs: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-mxs/devices/amba-duart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mxs/devices/amba-duart.c
b/arch/arm/mach-mxs/devices/amba-duart.c
index a559db0..a5479f7 100644
--- a/arch/arm/mach-mxs/devices/amba-duart.c
+++ b/arch/arm/mach-mxs/devices/amba-duart.c
@@ -23,7 +23,7 @@ const struct amba_device name##_device __initconst = {
\
.end = (soc ## _DUART_BASE_ADDR) + SZ_8K - 1, \
.flags = IORESOURCE_MEM,\
}, \
- .irq = {soc ## _INT_DUART, NO_IRQ}, \
+ .irq = {soc ## _INT_DUART}, \
}
#ifdef CONFIG_SOC_IMX23
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/31] ARM: amba: nomadik: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-nomadik/board-nhk8815.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-nomadik/board-nhk8815.c
b/arch/arm/mach-nomadik/board-nhk8815.c
index 7c878bf..721e51c 100644
--- a/arch/arm/mach-nomadik/board-nhk8815.c
+++ b/arch/arm/mach-nomadik/board-nhk8815.c
@@ -191,13 +191,13 @@ static void __init nhk8815_onenand_init(void)
static struct amba_device uart0_device = {
.dev = { .init_name = uart0 },
__MEM_4K_RESOURCE(NOMADIK_UART0_BASE),
- .irq = {IRQ_UART0, NO_IRQ},
+ .irq = {IRQ_UART0},
};
static struct amba_device uart1_device = {
.dev = { .init_name = uart1 },
__MEM_4K_RESOURCE(NOMADIK_UART1_BASE),
- .irq = {IRQ_UART1, NO_IRQ},
+ .irq = {IRQ_UART1},
};
static struct amba_device *amba_devs[] __initdata = {
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/31] ARM: amba: netx: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-netx/fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-netx/fb.c b/arch/arm/mach-netx/fb.c
index b991323..eda856c 100644
--- a/arch/arm/mach-netx/fb.c
+++ b/arch/arm/mach-netx/fb.c
@@ -102,7 +102,7 @@ static struct amba_device fb_device = {
.end= 0x00104fff,
.flags = IORESOURCE_MEM,
},
- .irq= { NETX_IRQ_LCD, NO_IRQ },
+ .irq= { NETX_IRQ_LCD },
};
int netx_fb_init(struct clcd_board *board, struct clcd_panel *panel)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/31] ARM: amba: spear: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-spear3xx/spear300.c |2 +-
arch/arm/mach-spear3xx/spear3xx.c |4 ++--
arch/arm/mach-spear6xx/spear6xx.c | 10 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-spear3xx/spear300.c
b/arch/arm/mach-spear3xx/spear300.c
index a5e46b4..6fdeec9 100644
--- a/arch/arm/mach-spear3xx/spear300.c
+++ b/arch/arm/mach-spear3xx/spear300.c
@@ -440,7 +440,7 @@ struct amba_device spear300_gpio1_device = {
.end = SPEAR300_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {SPEAR300_VIRQ_GPIO1, NO_IRQ},
+ .irq = {SPEAR300_VIRQ_GPIO1},
};
/* spear300 routines */
diff --git a/arch/arm/mach-spear3xx/spear3xx.c
b/arch/arm/mach-spear3xx/spear3xx.c
index 10af45d..bc4f1c6 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -38,7 +38,7 @@ struct amba_device spear3xx_gpio_device = {
.end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {SPEAR3XX_IRQ_BASIC_GPIO, NO_IRQ},
+ .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
};
/* uart device registration */
@@ -51,7 +51,7 @@ struct amba_device spear3xx_uart_device = {
.end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {SPEAR3XX_IRQ_UART, NO_IRQ},
+ .irq = {SPEAR3XX_IRQ_UART},
};
/* Do spear3xx familiy common initialization part here */
diff --git a/arch/arm/mach-spear6xx/spear6xx.c
b/arch/arm/mach-spear6xx/spear6xx.c
index e0f6628..b997b1b 100644
--- a/arch/arm/mach-spear6xx/spear6xx.c
+++ b/arch/arm/mach-spear6xx/spear6xx.c
@@ -34,7 +34,7 @@ struct amba_device uart_device[] = {
.end = SPEAR6XX_ICM1_UART0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_UART_0, NO_IRQ},
+ .irq = {IRQ_UART_0},
}, {
.dev = {
.init_name = uart1,
@@ -44,7 +44,7 @@ struct amba_device uart_device[] = {
.end = SPEAR6XX_ICM1_UART1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_UART_1, NO_IRQ},
+ .irq = {IRQ_UART_1},
}
};
@@ -73,7 +73,7 @@ struct amba_device gpio_device[] = {
.end = SPEAR6XX_CPU_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_LOCAL_GPIO, NO_IRQ},
+ .irq = {IRQ_LOCAL_GPIO},
}, {
.dev = {
.init_name = gpio1,
@@ -84,7 +84,7 @@ struct amba_device gpio_device[] = {
.end = SPEAR6XX_ICM3_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_BASIC_GPIO, NO_IRQ},
+ .irq = {IRQ_BASIC_GPIO},
}, {
.dev = {
.init_name = gpio2,
@@ -95,7 +95,7 @@ struct amba_device gpio_device[] = {
.end = SPEAR6XX_ICM2_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_APPL_GPIO, NO_IRQ},
+ .irq = {IRQ_APPL_GPIO},
}
};
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/31] ARM: amba: u300: get rid of NO_IRQ initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-u300/core.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index b4c6926..ed92967 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -105,7 +105,7 @@ static struct amba_device uart0_device = {
.end = U300_UART0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = { IRQ_U300_UART0, NO_IRQ },
+ .irq = { IRQ_U300_UART0 },
};
/* The U335 have an additional UART1 on the APP CPU */
@@ -129,7 +129,7 @@ static struct amba_device uart1_device = {
.end = U300_UART1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = { IRQ_U300_UART1, NO_IRQ },
+ .irq = { IRQ_U300_UART1 },
};
#endif
@@ -160,7 +160,7 @@ static struct amba_device pl022_device = {
.end = U300_SPI_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_U300_SPI, NO_IRQ },
+ .irq = {IRQ_U300_SPI },
/*
* This device has a DMA channel but the Linux driver does not use
* it currently.
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/31] ARM: amba: make use of -1 IRQs warn
Make the core warn about the use of -1 (NO_IRQ) Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/amba/bus.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c index d15acbb..01c2cf4 100644 --- a/drivers/amba/bus.c +++ b/drivers/amba/bus.c @@ -511,6 +511,9 @@ int amba_device_add(struct amba_device *dev, struct resource *parent) void __iomem *tmp; int i, ret; + WARN_ON(dev-irq[0] == (unsigned int)-1); + WARN_ON(dev-irq[1] == (unsigned int)-1); + ret = request_resource(parent, dev-res); if (ret) goto err_out; -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/31] ARM: amba: provide common initializers for static amba devices
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
include/linux/amba/bus.h | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index e192962..a9fab83 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -92,4 +92,37 @@ void amba_release_regions(struct amba_device *);
#define amba_manf(d) AMBA_MANF_BITS((d)-periphid)
#define amba_part(d) AMBA_PART_BITS((d)-periphid)
+#define __AMBA_DEV(busid, data, mask) \
+ { \
+ .coherent_dma_mask = mask, \
+ .init_name = busid, \
+ .platform_data = data, \
+ }
+
+/*
+ * APB devices do not themselves have the ability to address memory,
+ * so DMA masks should be zero (much like USB peripheral devices.)
+ * The DMA controller DMA masks should be used instead (much like
+ * USB host controllers in conventional PCs.)
+ */
+#define AMBA_APB_DEVICE(name, busid, id, base, irqs, data) \
+struct amba_device name##_device = { \
+ .dev = __AMBA_DEV(busid, data, 0), \
+ .res = DEFINE_RES_MEM(base, SZ_4K), \
+ .irq = irqs,\
+ .periphid = id, \
+}
+
+/*
+ * AHB devices are DMA capable, so set their DMA masks
+ */
+#define AMBA_AHB_DEVICE(name, busid, id, base, irqs, data) \
+struct amba_device name##_device = { \
+ .dev = __AMBA_DEV(busid, data, ~0ULL), \
+ .res = DEFINE_RES_MEM(base, SZ_4K), \
+ .dma_mask = ~0ULL, \
+ .irq = irqs,\
+ .periphid = id, \
+}
+
#endif
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/31] ARM: amba: vexpress: get rid of private platform amba_device initializer
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-vexpress/core.h | 17 -
arch/arm/mach-vexpress/ct-ca9x4.c |8
arch/arm/mach-vexpress/v2m.c | 20 ++--
3 files changed, 14 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
index f439715..9f0f282 100644
--- a/arch/arm/mach-vexpress/core.h
+++ b/arch/arm/mach-vexpress/core.h
@@ -1,19 +1,2 @@
#define __MMIO_P2V(x) (((x) 0xf) | (((x) 0x0f00) 4) |
0xf800)
#define MMIO_P2V(x)((void __iomem *)__MMIO_P2V(x))
-
-#define AMBA_DEVICE(name,busid,base,plat) \
-struct amba_device name##_device = { \
- .dev= { \
- .coherent_dma_mask = ~0UL, \
- .init_name = busid, \
- .platform_data = plat, \
- }, \
- .res= { \
- .start = base, \
- .end= base + SZ_4K - 1, \
- .flags = IORESOURCE_MEM, \
- }, \
- .dma_mask = ~0UL, \
- .irq= IRQ_##base, \
- /* .dma = DMA_##base,*/ \
-}
diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c
b/arch/arm/mach-vexpress/ct-ca9x4.c
index 2b1e836..3fde21c 100644
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@ -109,10 +109,10 @@ static struct clcd_board ct_ca9x4_clcd_data = {
.remove = versatile_clcd_remove_dma,
};
-static AMBA_DEVICE(clcd, ct:clcd, CT_CA9X4_CLCDC, ct_ca9x4_clcd_data);
-static AMBA_DEVICE(dmc, ct:dmc, CT_CA9X4_DMC, NULL);
-static AMBA_DEVICE(smc, ct:smc, CT_CA9X4_SMC, NULL);
-static AMBA_DEVICE(gpio, ct:gpio, CT_CA9X4_GPIO, NULL);
+static AMBA_AHB_DEVICE(clcd, ct:clcd, 0, CT_CA9X4_CLCDC, IRQ_CT_CA9X4_CLCDC,
ct_ca9x4_clcd_data);
+static AMBA_APB_DEVICE(dmc, ct:dmc, 0, CT_CA9X4_DMC, IRQ_CT_CA9X4_DMC, NULL);
+static AMBA_APB_DEVICE(smc, ct:smc, 0, CT_CA9X4_SMC, IRQ_CT_CA9X4_SMC, NULL);
+static AMBA_APB_DEVICE(gpio, ct:gpio, 0, CT_CA9X4_GPIO, IRQ_CT_CA9X4_GPIO,
NULL);
static struct amba_device *ct_ca9x4_amba_devs[] __initdata = {
clcd_device,
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index b4a28ca..ad64f97 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -266,16 +266,16 @@ static struct mmci_platform_data v2m_mmci_data = {
.status = v2m_mmci_status,
};
-static AMBA_DEVICE(aaci, mb:aaci, V2M_AACI, NULL);
-static AMBA_DEVICE(mmci, mb:mmci, V2M_MMCI, v2m_mmci_data);
-static AMBA_DEVICE(kmi0, mb:kmi0, V2M_KMI0, NULL);
-static AMBA_DEVICE(kmi1, mb:kmi1, V2M_KMI1, NULL);
-static AMBA_DEVICE(uart0, mb:uart0, V2M_UART0, NULL);
-static AMBA_DEVICE(uart1, mb:uart1, V2M_UART1, NULL);
-static AMBA_DEVICE(uart2, mb:uart2, V2M_UART2, NULL);
-static AMBA_DEVICE(uart3, mb:uart3, V2M_UART3, NULL);
-static AMBA_DEVICE(wdt, mb:wdt, V2M_WDT, NULL);
-static AMBA_DEVICE(rtc, mb:rtc, V2M_RTC, NULL);
+static AMBA_APB_DEVICE(aaci, mb:aaci, 0, V2M_AACI, IRQ_V2M_AACI, NULL);
+static AMBA_APB_DEVICE(mmci, mb:mmci, 0, V2M_MMCI, IRQ_V2M_MMCI,
v2m_mmci_data);
+static AMBA_APB_DEVICE(kmi0, mb:kmi0, 0, V2M_KMI0, IRQ_V2M_KMI0, NULL);
+static AMBA_APB_DEVICE(kmi1, mb:kmi1, 0, V2M_KMI1, IRQ_V2M_KMI1, NULL);
+static AMBA_APB_DEVICE(uart0, mb:uart0, 0, V2M_UART0, IRQ_V2M_UART0, NULL);
+static AMBA_APB_DEVICE(uart1, mb:uart1, 0, V2M_UART1, IRQ_V2M_UART1, NULL);
+static AMBA_APB_DEVICE(uart2, mb:uart2, 0, V2M_UART2, IRQ_V2M_UART2, NULL);
+static AMBA_APB_DEVICE(uart3, mb:uart3, 0, V2M_UART3, IRQ_V2M_UART3, NULL);
+static AMBA_APB_DEVICE(wdt, mb:wdt, 0, V2M_WDT, IRQ_V2M_WDT, NULL);
+static AMBA_APB_DEVICE(rtc, mb:rtc, 0, V2M_RTC, IRQ_V2M_RTC, NULL);
static struct amba_device *v2m_amba_devs[] __initdata = {
aaci_device,
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/31] ARM: amba: versatile: get rid of private platform amba_device initializer
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-versatile/core.c | 36
arch/arm/mach-versatile/core.h | 20 -
arch/arm/mach-versatile/versatile_pb.c | 10
3 files changed, 28 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 358cc0b..4f352e4 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -614,26 +614,26 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define SSP_IRQ{ IRQ_SSPINT }
/* FPGA Primecells */
-AMBA_DEVICE(aaci, fpga:04, AACI, NULL);
-AMBA_DEVICE(mmc0, fpga:05, MMCI0,mmc0_plat_data);
-AMBA_DEVICE(kmi0, fpga:06, KMI0, NULL);
-AMBA_DEVICE(kmi1, fpga:07, KMI1, NULL);
+APB_DEVICE(aaci, fpga:04, AACI, NULL);
+APB_DEVICE(mmc0, fpga:05, MMCI0,mmc0_plat_data);
+APB_DEVICE(kmi0, fpga:06, KMI0, NULL);
+APB_DEVICE(kmi1, fpga:07, KMI1, NULL);
/* DevChip Primecells */
-AMBA_DEVICE(smc, dev:00, SMC, NULL);
-AMBA_DEVICE(mpmc, dev:10, MPMC, NULL);
-AMBA_DEVICE(clcd, dev:20, CLCD, clcd_plat_data);
-AMBA_DEVICE(dmac, dev:30, DMAC, NULL);
-AMBA_DEVICE(sctl, dev:e0, SCTL, NULL);
-AMBA_DEVICE(wdog, dev:e1, WATCHDOG, NULL);
-AMBA_DEVICE(gpio0, dev:e4, GPIO0,gpio0_plat_data);
-AMBA_DEVICE(gpio1, dev:e5, GPIO1,gpio1_plat_data);
-AMBA_DEVICE(rtc, dev:e8, RTC, NULL);
-AMBA_DEVICE(sci0, dev:f0, SCI, NULL);
-AMBA_DEVICE(uart0, dev:f1, UART0,NULL);
-AMBA_DEVICE(uart1, dev:f2, UART1,NULL);
-AMBA_DEVICE(uart2, dev:f3, UART2,NULL);
-AMBA_DEVICE(ssp0, dev:f4, SSP, ssp0_plat_data);
+AHB_DEVICE(smc, dev:00, SMC, NULL);
+AHB_DEVICE(mpmc, dev:10, MPMC, NULL);
+AHB_DEVICE(clcd, dev:20, CLCD, clcd_plat_data);
+AHB_DEVICE(dmac, dev:30, DMAC, NULL);
+APB_DEVICE(sctl, dev:e0, SCTL, NULL);
+APB_DEVICE(wdog, dev:e1, WATCHDOG, NULL);
+APB_DEVICE(gpio0, dev:e4, GPIO0,gpio0_plat_data);
+APB_DEVICE(gpio1, dev:e5, GPIO1,gpio1_plat_data);
+APB_DEVICE(rtc, dev:e8, RTC, NULL);
+APB_DEVICE(sci0, dev:f0, SCI, NULL);
+APB_DEVICE(uart0, dev:f1, UART0,NULL);
+APB_DEVICE(uart1, dev:f2, UART1,NULL);
+APB_DEVICE(uart2, dev:f3, UART2,NULL);
+APB_DEVICE(ssp0, dev:f4, SSP, ssp0_plat_data);
static struct amba_device *amba_devs[] __initdata = {
dmac_device,
diff --git a/arch/arm/mach-versatile/core.h b/arch/arm/mach-versatile/core.h
index 2ef2f55..683e607 100644
--- a/arch/arm/mach-versatile/core.h
+++ b/arch/arm/mach-versatile/core.h
@@ -36,20 +36,10 @@ extern unsigned int mmc_status(struct device *dev);
extern struct of_dev_auxdata versatile_auxdata_lookup[];
#endif
-#define AMBA_DEVICE(name,busid,base,plat) \
-static struct amba_device name##_device = {\
- .dev= { \
- .coherent_dma_mask = ~0,\
- .init_name = busid, \
- .platform_data = plat, \
- }, \
- .res= { \
- .start = VERSATILE_##base##_BASE, \
- .end= (VERSATILE_##base##_BASE) + SZ_4K - 1,\
- .flags = IORESOURCE_MEM, \
- }, \
- .dma_mask = ~0, \
- .irq= base##_IRQ, \
-}
+#define APB_DEVICE(name, busid, base, plat)\
+static AMBA_APB_DEVICE(name, busid, 0, VERSATILE_##base##_BASE, base##_IRQ,
plat)
+
+#define AHB_DEVICE(name, busid, base, plat)\
+static AMBA_AHB_DEVICE(name, busid, 0, VERSATILE_##base##_BASE, base##_IRQ,
plat)
#endif
diff --git a/arch/arm/mach-versatile/versatile_pb.c
b/arch/arm/mach-versatile/versatile_pb.c
index 1a5fe6e..1973833 100644
--- a/arch/arm/mach-versatile/versatile_pb.c
+++ b/arch/arm/mach-versatile/versatile_pb.c
@@ -73,13 +73,13 @@ static struct pl061_platform_data gpio3_plat_data = {
*/
/* FPGA Primecells */
-AMBA_DEVICE(uart3, fpga:09, UART3,NULL);
-AMBA_DEVICE(sci1, fpga:0a, SCI1, NULL);
-AMBA_DEVICE(mmc1, fpga:0b, MMCI1,mmc1_plat_data);
+APB_DEVICE(uart3, fpga:09, UART3,NULL);
+APB_DEVICE(sci1, fpga:0a, SCI1, NULL);
+APB_DEVICE(mmc1, fpga:0b, MMCI1,mmc1_plat_data);
/* DevChip Primecells */
-AMBA_DEVICE(gpio2, dev:e6, GPIO2,gpio2_plat_data);
-AMBA_DEVICE(gpio3, dev:e7, GPIO3,gpio3_plat_data);
+APB_DEVICE(gpio2, dev:e6, GPIO2,gpio2_plat_data);
+APB_DEVICE(gpio3, dev:e7, GPIO3,gpio3_plat_data);
static struct amba_device *amba_devs[] __initdata = {
uart3_device,
--
1.7.4.4
--
To unsubscribe from
[PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-realview/core.h| 20 ---
arch/arm/mach-realview/realview_eb.c | 38 +++---
arch/arm/mach-realview/realview_pb1176.c | 38 +++---
arch/arm/mach-realview/realview_pb11mp.c | 38 +++---
arch/arm/mach-realview/realview_pba8.c | 38 +++---
arch/arm/mach-realview/realview_pbx.c| 38 +++---
6 files changed, 100 insertions(+), 110 deletions(-)
diff --git a/arch/arm/mach-realview/core.h b/arch/arm/mach-realview/core.h
index 735b57a..b1c6097 100644
--- a/arch/arm/mach-realview/core.h
+++ b/arch/arm/mach-realview/core.h
@@ -28,21 +28,11 @@
#include asm/setup.h
#include asm/leds.h
-#define AMBA_DEVICE(name,busid,base,plat) \
-static struct amba_device name##_device = {\
- .dev= { \
- .coherent_dma_mask = ~0,\
- .init_name = busid, \
- .platform_data = plat, \
- }, \
- .res= { \
- .start = REALVIEW_##base##_BASE, \
- .end= (REALVIEW_##base##_BASE) + SZ_4K - 1, \
- .flags = IORESOURCE_MEM, \
- }, \
- .dma_mask = ~0, \
- .irq= base##_IRQ, \
-}
+#define APB_DEVICE(name, busid, base, plat)\
+static AMBA_APB_DEVICE(name, busid, 0, base, base##_IRQ, plat)
+
+#define AHB_DEVICE(name, busid, base, plat)\
+static AMBA_AHB_DEVICE(name, busid, 0, base, base##_IRQ, plat)
struct machine_desc;
diff --git a/arch/arm/mach-realview/realview_eb.c
b/arch/arm/mach-realview/realview_eb.c
index 5c810e5..fbca43c 100644
--- a/arch/arm/mach-realview/realview_eb.c
+++ b/arch/arm/mach-realview/realview_eb.c
@@ -176,27 +176,27 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define EB_SSP_IRQ { IRQ_EB_SSP }
/* FPGA Primecells */
-AMBA_DEVICE(aaci, fpga:aaci, AACI, NULL);
-AMBA_DEVICE(mmc0, fpga:mmc0, MMCI0,realview_mmc0_plat_data);
-AMBA_DEVICE(kmi0, fpga:kmi0, KMI0, NULL);
-AMBA_DEVICE(kmi1, fpga:kmi1, KMI1, NULL);
-AMBA_DEVICE(uart3, fpga:uart3, EB_UART3, NULL);
+APB_DEVICE(aaci, fpga:aaci, AACI, NULL);
+APB_DEVICE(mmc0, fpga:mmc0, MMCI0,realview_mmc0_plat_data);
+APB_DEVICE(kmi0, fpga:kmi0, KMI0, NULL);
+APB_DEVICE(kmi1, fpga:kmi1, KMI1, NULL);
+APB_DEVICE(uart3, fpga:uart3, EB_UART3, NULL);
/* DevChip Primecells */
-AMBA_DEVICE(smc, dev:smc, EB_SMC, NULL);
-AMBA_DEVICE(clcd, dev:clcd, EB_CLCD, clcd_plat_data);
-AMBA_DEVICE(dmac, dev:dmac, DMAC, NULL);
-AMBA_DEVICE(sctl, dev:sctl, SCTL, NULL);
-AMBA_DEVICE(wdog, dev:wdog, EB_WATCHDOG, NULL);
-AMBA_DEVICE(gpio0, dev:gpio0, EB_GPIO0, gpio0_plat_data);
-AMBA_DEVICE(gpio1, dev:gpio1, GPIO1,gpio1_plat_data);
-AMBA_DEVICE(gpio2, dev:gpio2, GPIO2,gpio2_plat_data);
-AMBA_DEVICE(rtc, dev:rtc, EB_RTC, NULL);
-AMBA_DEVICE(sci0, dev:sci0, SCI, NULL);
-AMBA_DEVICE(uart0, dev:uart0, EB_UART0, NULL);
-AMBA_DEVICE(uart1, dev:uart1, EB_UART1, NULL);
-AMBA_DEVICE(uart2, dev:uart2, EB_UART2, NULL);
-AMBA_DEVICE(ssp0, dev:ssp0, EB_SSP, ssp0_plat_data);
+AHB_DEVICE(smc, dev:smc, EB_SMC, NULL);
+AHB_DEVICE(clcd, dev:clcd, EB_CLCD, clcd_plat_data);
+AHB_DEVICE(dmac, dev:dmac, DMAC, NULL);
+AHB_DEVICE(sctl, dev:sctl, SCTL, NULL);
+APB_DEVICE(wdog, dev:wdog, EB_WATCHDOG, NULL);
+APB_DEVICE(gpio0, dev:gpio0, EB_GPIO0, gpio0_plat_data);
+APB_DEVICE(gpio1, dev:gpio1, GPIO1,gpio1_plat_data);
+APB_DEVICE(gpio2, dev:gpio2, GPIO2,gpio2_plat_data);
+APB_DEVICE(rtc, dev:rtc, EB_RTC, NULL);
+APB_DEVICE(sci0, dev:sci0, SCI, NULL);
+APB_DEVICE(uart0, dev:uart0, EB_UART0, NULL);
+APB_DEVICE(uart1, dev:uart1, EB_UART1, NULL);
+APB_DEVICE(uart2, dev:uart2, EB_UART2, NULL);
+APB_DEVICE(ssp0, dev:ssp0, EB_SSP, ssp0_plat_data);
static struct amba_device *amba_devs[] __initdata = {
dmac_device,
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 9506de9..1b6e60c 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -155,27 +155,27 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_SSP_IRQ { IRQ_DC1176_SSP }
/* FPGA Primecells */
-AMBA_DEVICE(aaci, fpga:aaci,AACI, NULL);
-AMBA_DEVICE(mmc0, fpga:mmc0,MMCI0,
realview_mmc0_plat_data);
-AMBA_DEVICE(kmi0,
[PATCH 22/31] ARM: amba: integrator: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-integrator/core.c | 70 ++
arch/arm/mach-integrator/integrator_cp.c | 49 -
2 files changed, 22 insertions(+), 97 deletions(-)
diff --git a/arch/arm/mach-integrator/core.c b/arch/arm/mach-integrator/core.c
index 29baef9..15b87f2 100644
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@ -35,67 +35,23 @@
static struct amba_pl010_data integrator_uart_data;
-static struct amba_device rtc_device = {
- .dev= {
- .init_name = mb:15,
- },
- .res= {
- .start = INTEGRATOR_RTC_BASE,
- .end= INTEGRATOR_RTC_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_RTCINT },
-};
+#define INTEGRATOR_RTC_IRQ { IRQ_RTCINT }
+#define INTEGRATOR_UART0_IRQ { IRQ_UARTINT0 }
+#define INTEGRATOR_UART1_IRQ { IRQ_UARTINT1 }
+#define KMI0_IRQ { IRQ_KMIINT0 }
+#define KMI1_IRQ { IRQ_KMIINT1 }
-static struct amba_device uart0_device = {
- .dev= {
- .init_name = mb:16,
- .platform_data = integrator_uart_data,
- },
- .res= {
- .start = INTEGRATOR_UART0_BASE,
- .end= INTEGRATOR_UART0_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_UARTINT0 },
-};
+static AMBA_APB_DEVICE(rtc, mb:15, 0,
+ INTEGRATOR_RTC_BASE, INTEGRATOR_RTC_IRQ, NULL);
-static struct amba_device uart1_device = {
- .dev= {
- .init_name = mb:17,
- .platform_data = integrator_uart_data,
- },
- .res= {
- .start = INTEGRATOR_UART1_BASE,
- .end= INTEGRATOR_UART1_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_UARTINT1 },
-};
+static AMBA_APB_DEVICE(uart0, mb:16, 0,
+ INTEGRATOR_UART0_BASE, INTEGRATOR_UART0_IRQ, integrator_uart_data);
-static struct amba_device kmi0_device = {
- .dev= {
- .init_name = mb:18,
- },
- .res= {
- .start = KMI0_BASE,
- .end= KMI0_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_KMIINT0 },
-};
+static AMBA_APB_DEVICE(uart1, mb:17, 0,
+ INTEGRATOR_UART1_BASE, INTEGRATOR_UART1_IRQ, integrator_uart_data);
-static struct amba_device kmi1_device = {
- .dev= {
- .init_name = mb:19,
- },
- .res= {
- .start = KMI1_BASE,
- .end= KMI1_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_KMIINT1 },
-};
+static AMBA_APB_DEVICE(kmi0, mb:18, 0, KMI0_BASE, KMI0_IRQ, NULL);
+static AMBA_APB_DEVICE(kmi1, mb:19, 0, KMI1_BASE, KMI1_IRQ, NULL);
static struct amba_device *amba_devs[] __initdata = {
rtc_device,
diff --git a/arch/arm/mach-integrator/integrator_cp.c
b/arch/arm/mach-integrator/integrator_cp.c
index ecc08ed..be9ead4 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -347,32 +347,14 @@ static struct mmci_platform_data mmc_data = {
.gpio_cd= -1,
};
-static struct amba_device mmc_device = {
- .dev= {
- .init_name = mb:1c,
- .platform_data = mmc_data,
- },
- .res= {
- .start = INTEGRATOR_CP_MMC_BASE,
- .end= INTEGRATOR_CP_MMC_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_CP_MMCIINT0, IRQ_CP_MMCIINT1 },
- .periphid = 0,
-};
+#define INTEGRATOR_CP_MMC_IRQS { IRQ_CP_MMCIINT0, IRQ_CP_MMCIINT1 }
+#define INTEGRATOR_CP_AACI_IRQS{ IRQ_CP_AACIINT }
-static struct amba_device aaci_device = {
- .dev= {
- .init_name = mb:1d,
- },
- .res= {
- .start = INTEGRATOR_CP_AACI_BASE,
- .end= INTEGRATOR_CP_AACI_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_CP_AACIINT },
- .periphid = 0,
-};
+static AMBA_APB_DEVICE(mmc, mb:1c, 0, INTEGRATOR_CP_MMC_BASE,
+ INTEGRATOR_CP_MMC_IRQS, mmc_data);
+
+static AMBA_APB_DEVICE(aaci, mb:1d, 0, INTEGRATOR_CP_AACI_BASE,
+ INTEGRATOR_CP_AACI_IRQS, NULL);
/*
@@ -425,21 +407,8 @@ static struct clcd_board clcd_data = {
.remove = versatile_clcd_remove_dma,
};
-static struct amba_device clcd_device = {
- .dev= {
- .init_name = mb:c0,
- .coherent_dma_mask = ~0,
- .platform_data = clcd_data,
- },
[PATCH 24/31] ARM: amba: ep93xx: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-ep93xx/core.c | 46 +-
1 files changed, 6 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 1a8397a..903edb0 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -279,48 +279,14 @@ static struct amba_pl010_data ep93xx_uart_data = {
.set_mctrl = ep93xx_uart_set_mctrl,
};
-static struct amba_device uart1_device = {
- .dev= {
- .init_name = apb:uart1,
- .platform_data = ep93xx_uart_data,
- },
- .res= {
- .start = EP93XX_UART1_PHYS_BASE,
- .end= EP93XX_UART1_PHYS_BASE + 0x0fff,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_EP93XX_UART1 },
- .periphid = 0x00041010,
-};
-
-static struct amba_device uart2_device = {
- .dev= {
- .init_name = apb:uart2,
- .platform_data = ep93xx_uart_data,
- },
- .res= {
- .start = EP93XX_UART2_PHYS_BASE,
- .end= EP93XX_UART2_PHYS_BASE + 0x0fff,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_EP93XX_UART2 },
- .periphid = 0x00041010,
-};
+static AMBA_APB_DEVICE(uart1, apb:uart1, 0x00041010, EP93XX_UART1_PHYS_BASE,
+ { IRQ_EP93XX_UART1 }, ep93xx_uart_data);
-static struct amba_device uart3_device = {
- .dev= {
- .init_name = apb:uart3,
- .platform_data = ep93xx_uart_data,
- },
- .res= {
- .start = EP93XX_UART3_PHYS_BASE,
- .end= EP93XX_UART3_PHYS_BASE + 0x0fff,
- .flags = IORESOURCE_MEM,
- },
- .irq= { IRQ_EP93XX_UART3 },
- .periphid = 0x00041010,
-};
+static AMBA_APB_DEVICE(uart2, apb:uart2, 0x00041010, EP93XX_UART2_PHYS_BASE,
+ { IRQ_EP93XX_UART2 }, ep93xx_uart_data);
+static AMBA_APB_DEVICE(uart3, apb:uart3, 0x00041010, EP93XX_UART3_PHYS_BASE,
+ { IRQ_EP93XX_UART3 }, ep93xx_uart_data);
static struct resource ep93xx_rtc_resource[] = {
{
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/31] ARM: amba: spear: get rid of NO_IRQ initializers
On 1/20/2012 2:57 PM, Russell King - ARM Linux wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-spear3xx/spear300.c |2 +-
arch/arm/mach-spear3xx/spear3xx.c |4 ++--
arch/arm/mach-spear6xx/spear6xx.c | 10 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-spear3xx/spear300.c
b/arch/arm/mach-spear3xx/spear300.c
index a5e46b4..6fdeec9 100644
--- a/arch/arm/mach-spear3xx/spear300.c
+++ b/arch/arm/mach-spear3xx/spear300.c
@@ -440,7 +440,7 @@ struct amba_device spear300_gpio1_device = {
.end = SPEAR300_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {SPEAR300_VIRQ_GPIO1, NO_IRQ},
+ .irq = {SPEAR300_VIRQ_GPIO1},
};
/* spear300 routines */
diff --git a/arch/arm/mach-spear3xx/spear3xx.c
b/arch/arm/mach-spear3xx/spear3xx.c
index 10af45d..bc4f1c6 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -38,7 +38,7 @@ struct amba_device spear3xx_gpio_device = {
.end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {SPEAR3XX_IRQ_BASIC_GPIO, NO_IRQ},
+ .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
};
/* uart device registration */
@@ -51,7 +51,7 @@ struct amba_device spear3xx_uart_device = {
.end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {SPEAR3XX_IRQ_UART, NO_IRQ},
+ .irq = {SPEAR3XX_IRQ_UART},
};
/* Do spear3xx familiy common initialization part here */
diff --git a/arch/arm/mach-spear6xx/spear6xx.c
b/arch/arm/mach-spear6xx/spear6xx.c
index e0f6628..b997b1b 100644
--- a/arch/arm/mach-spear6xx/spear6xx.c
+++ b/arch/arm/mach-spear6xx/spear6xx.c
@@ -34,7 +34,7 @@ struct amba_device uart_device[] = {
.end = SPEAR6XX_ICM1_UART0_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_UART_0, NO_IRQ},
+ .irq = {IRQ_UART_0},
}, {
.dev = {
.init_name = uart1,
@@ -44,7 +44,7 @@ struct amba_device uart_device[] = {
.end = SPEAR6XX_ICM1_UART1_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_UART_1, NO_IRQ},
+ .irq = {IRQ_UART_1},
}
};
@@ -73,7 +73,7 @@ struct amba_device gpio_device[] = {
.end = SPEAR6XX_CPU_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_LOCAL_GPIO, NO_IRQ},
+ .irq = {IRQ_LOCAL_GPIO},
}, {
.dev = {
.init_name = gpio1,
@@ -84,7 +84,7 @@ struct amba_device gpio_device[] = {
.end = SPEAR6XX_ICM3_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_BASIC_GPIO, NO_IRQ},
+ .irq = {IRQ_BASIC_GPIO},
}, {
.dev = {
.init_name = gpio2,
@@ -95,7 +95,7 @@ struct amba_device gpio_device[] = {
.end = SPEAR6XX_ICM2_GPIO_BASE + SZ_4K - 1,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_APPL_GPIO, NO_IRQ},
+ .irq = {IRQ_APPL_GPIO},
}
};
Acked-by: Viresh Kumar viresh.ku...@st.com
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/31] ARM: amba: bcmring: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-bcmring/core.c | 23 ++-
1 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-bcmring/core.c b/arch/arm/mach-bcmring/core.c
index 6b67b7e..22e4e0a 100644
--- a/arch/arm/mach-bcmring/core.c
+++ b/arch/arm/mach-bcmring/core.c
@@ -52,27 +52,8 @@
#include mach/csp/chipcHw_inline.h
#include mach/csp/tmrHw_reg.h
-#define AMBA_DEVICE(name, initname, base, plat, size) \
-static struct amba_device name##_device = { \
- .dev = { \
- .coherent_dma_mask = ~0, \
- .init_name = initname,\
- .platform_data = plat \
- }, \
- .res = { \
- .start = MM_ADDR_IO_##base, \
- .end = MM_ADDR_IO_##base + (size) - 1,\
- .flags = IORESOURCE_MEM \
- }, \
- .dma_mask = ~0, \
- .irq = { \
- IRQ_##base\
- }\
-}
-
-
-AMBA_DEVICE(uartA, uarta, UARTA, NULL, SZ_4K);
-AMBA_DEVICE(uartB, uartb, UARTB, NULL, SZ_4K);
+static AMBA_APB_DEVICE(uartA, uarta, MM_ADDR_IO_UARTA, { IRQ_UARTA }, NULL);
+static AMBA_APB_DEVICE(uartB, uartb, MM_ADDR_IO_UARTB, { IRQ_UARTB }, NULL);
static struct clk pll1_clk = {
.name = PLL1,
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/31] ARM: amba: netx: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-netx/fb.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-netx/fb.c b/arch/arm/mach-netx/fb.c
index eda856c..2cdf6ef 100644
--- a/arch/arm/mach-netx/fb.c
+++ b/arch/arm/mach-netx/fb.c
@@ -92,18 +92,7 @@ void clk_put(struct clk *clk)
{
}
-static struct amba_device fb_device = {
- .dev= {
- .init_name = fb,
- .coherent_dma_mask = ~0,
- },
- .res= {
- .start = 0x00104000,
- .end= 0x00104fff,
- .flags = IORESOURCE_MEM,
- },
- .irq= { NETX_IRQ_LCD },
-};
+static AMBA_AHB_DEVICE(fb, fb, 0, 0x00104000, { NETX_IRQ_LCD }, NULL);
int netx_fb_init(struct clcd_board *board, struct clcd_panel *panel)
{
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/31] ARM: amba: lpc32xx: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-lpc32xx/phy3250.c | 32
1 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index 025eb21..5d51c10 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -149,20 +149,8 @@ static struct clcd_board lpc32xx_clcd_data = {
.remove = lpc32xx_clcd_remove,
};
-static struct amba_device lpc32xx_clcd_device = {
- .dev= {
- .coherent_dma_mask = ~0,
- .init_name = dev:clcd,
- .platform_data = lpc32xx_clcd_data,
- },
- .res= {
- .start = LPC32XX_LCD_BASE,
- .end= (LPC32XX_LCD_BASE + SZ_4K - 1),
- .flags = IORESOURCE_MEM,
- },
- .dma_mask = ~0,
- .irq= {IRQ_LPC32XX_LCD},
-};
+static AMBA_AHB_DEVICE(lpc32xx_clcd, dev:clcd, 0,
+ LPC32XX_LCD_BASE, { IRQ_LPC32XX_LCD }, lpc32xx_clcd_data);
/*
* AMBA SSP (SPI)
@@ -191,20 +179,8 @@ static struct pl022_ssp_controller lpc32xx_ssp0_data = {
.enable_dma = 0,
};
-static struct amba_device lpc32xx_ssp0_device = {
- .dev= {
- .coherent_dma_mask = ~0,
- .init_name = dev:ssp0,
- .platform_data = lpc32xx_ssp0_data,
- },
- .res= {
- .start = LPC32XX_SSP0_BASE,
- .end= (LPC32XX_SSP0_BASE + SZ_4K - 1),
- .flags = IORESOURCE_MEM,
- },
- .dma_mask = ~0,
- .irq= {IRQ_LPC32XX_SSP0},
-};
+static AMBA_APB_DEVICE(lpc32xx_ssp0, dev:ssp0, 0,
+ LPC32XX_SSP0_BASE, { IRQ_LPC32XX_SSP0 }, lpc32xx_ssp0_data);
/* AT25 driver registration */
static int __init phy3250_spi_board_register(void)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 28/31] ARM: amba: u300: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-u300/core.c | 85
1 files changed, 16 insertions(+), 69 deletions(-)
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index ed92967..b986560 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -94,19 +94,9 @@ static struct amba_pl011_data uart0_plat_data = {
#endif
};
-static struct amba_device uart0_device = {
- .dev = {
- .coherent_dma_mask = ~0,
- .init_name = uart0, /* Slow device at 0x3000 offset */
- .platform_data = uart0_plat_data,
- },
- .res = {
- .start = U300_UART0_BASE,
- .end = U300_UART0_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = { IRQ_U300_UART0 },
-};
+/* Slow device at 0x3000 offset */
+static AMBA_APB_DEVICE(uart0, uart0, 0, U300_UART0_BASE,
+ { IRQ_U300_UART0 }, uart0_plat_data);
/* The U335 have an additional UART1 on the APP CPU */
#ifdef CONFIG_MACH_U300_BS335
@@ -118,71 +108,28 @@ static struct amba_pl011_data uart1_plat_data = {
#endif
};
-static struct amba_device uart1_device = {
- .dev = {
- .coherent_dma_mask = ~0,
- .init_name = uart1, /* Fast device at 0x7000 offset */
- .platform_data = uart1_plat_data,
- },
- .res = {
- .start = U300_UART1_BASE,
- .end = U300_UART1_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = { IRQ_U300_UART1 },
-};
+/* Fast device at 0x7000 offset */
+static AMBA_APB_DEVICE(uart1, uart1, 0, U300_UART1_BASE,
+ { IRQ_U300_UART1 }, uart1_plat_data);
#endif
-static struct amba_device pl172_device = {
- .dev = {
- .init_name = pl172, /* AHB device at 0x4000 offset */
- .platform_data = NULL,
- },
- .res = {
- .start = U300_EMIF_CFG_BASE,
- .end = U300_EMIF_CFG_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
-};
+/* AHB device at 0x4000 offset */
+static AMBA_APB_DEVICE(pl172, pl172, 0, U300_EMIF_CFG_BASE, { }, NULL);
/*
* Everything within this next ifdef deals with external devices connected to
* the APP SPI bus.
*/
-static struct amba_device pl022_device = {
- .dev = {
- .coherent_dma_mask = ~0,
- .init_name = pl022, /* Fast device at 0x6000 offset */
- },
- .res = {
- .start = U300_SPI_BASE,
- .end = U300_SPI_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_U300_SPI },
- /*
-* This device has a DMA channel but the Linux driver does not use
-* it currently.
-*/
-};
+/* Fast device at 0x6000 offset */
+static AMBA_APB_DEVICE(pl022, pl022, 0, U300_SPI_BASE,
+ { IRQ_U300_SPI }, NULL);
-static struct amba_device mmcsd_device = {
- .dev = {
- .init_name = mmci, /* Fast device at 0x1000 offset */
- .platform_data = NULL, /* Added later */
- },
- .res = {
- .start = U300_MMCSD_BASE,
- .end = U300_MMCSD_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_U300_MMCSD_MCIINTR0, IRQ_U300_MMCSD_MCIINTR1 },
- /*
-* This device has a DMA channel but the Linux driver does not use
-* it currently.
-*/
-};
+/* Fast device at 0x1000 offset */
+#define U300_MMCSD_IRQS{ IRQ_U300_MMCSD_MCIINTR0,
IRQ_U300_MMCSD_MCIINTR1 }
+
+static AMBA_APB_DEVICE(mmcsd, mmci, 0, U300_MMCSD_BASE,
+ U300_MMCSD_IRQS, NULL);
/*
* The order of device declaration may be important, since some devices
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/31] ARM: amba: nomadik: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-nomadik/board-nhk8815.c | 17 -
arch/arm/mach-nomadik/cpu-8815.c |9 ++---
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-nomadik/board-nhk8815.c
b/arch/arm/mach-nomadik/board-nhk8815.c
index 721e51c..f6f74ad 100644
--- a/arch/arm/mach-nomadik/board-nhk8815.c
+++ b/arch/arm/mach-nomadik/board-nhk8815.c
@@ -185,20 +185,11 @@ static void __init nhk8815_onenand_init(void)
#endif
}
-#define __MEM_4K_RESOURCE(x) \
- .res = {.start = (x), .end = (x) + SZ_4K - 1, .flags = IORESOURCE_MEM}
+static AMBA_APB_DEVICE(uart0, uart0, 0, NOMADIK_UART0_BASE,
+ { IRQ_UART0 }, NULL);
-static struct amba_device uart0_device = {
- .dev = { .init_name = uart0 },
- __MEM_4K_RESOURCE(NOMADIK_UART0_BASE),
- .irq = {IRQ_UART0},
-};
-
-static struct amba_device uart1_device = {
- .dev = { .init_name = uart1 },
- __MEM_4K_RESOURCE(NOMADIK_UART1_BASE),
- .irq = {IRQ_UART1},
-};
+static AMBA_APB_DEVICE(uart1, uart1, 0, NOMADIK_UART1_BASE,
+ { IRQ_UART1 }, NULL);
static struct amba_device *amba_devs[] __initdata = {
uart0_device,
diff --git a/arch/arm/mach-nomadik/cpu-8815.c b/arch/arm/mach-nomadik/cpu-8815.c
index 65df7b4..27f43a4 100644
--- a/arch/arm/mach-nomadik/cpu-8815.c
+++ b/arch/arm/mach-nomadik/cpu-8815.c
@@ -97,12 +97,7 @@ static struct platform_device cpu8815_platform_gpio[] = {
GPIO_DEVICE(3),
};
-static struct amba_device cpu8815_amba_rng = {
- .dev = {
- .init_name = rng,
- },
- __MEM_4K_RESOURCE(NOMADIK_RNG_BASE),
-};
+static AMBA_APB_DEVICE(cpu8815_amba_rng, rng, 0, NOMADIK_RNG_BASE, { },
NULL);
static struct platform_device *platform_devs[] __initdata = {
cpu8815_platform_gpio + 0,
@@ -112,7 +107,7 @@ static struct platform_device *platform_devs[] __initdata =
{
};
static struct amba_device *amba_devs[] __initdata = {
- cpu8815_amba_rng
+ cpu8815_amba_rng_device
};
static int __init cpu8815_init(void)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 30/31] ARM: amba: spear: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-spear3xx/spear300.c | 14 ++
arch/arm/mach-spear3xx/spear3xx.c | 27 ---
2 files changed, 6 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-spear3xx/spear300.c
b/arch/arm/mach-spear3xx/spear300.c
index 6fdeec9..9da50e281 100644
--- a/arch/arm/mach-spear3xx/spear300.c
+++ b/arch/arm/mach-spear3xx/spear300.c
@@ -430,18 +430,8 @@ static struct pl061_platform_data gpio1_plat_data = {
.irq_base = SPEAR300_GPIO1_INT_BASE,
};
-struct amba_device spear300_gpio1_device = {
- .dev = {
- .init_name = gpio1,
- .platform_data = gpio1_plat_data,
- },
- .res = {
- .start = SPEAR300_GPIO_BASE,
- .end = SPEAR300_GPIO_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {SPEAR300_VIRQ_GPIO1},
-};
+AMBA_APB_DEVICE(spear300_gpio1, gpio1, 0, SPEAR300_GPIO_BASE,
+ {SPEAR300_VIRQ_GPIO1}, gpio1_plat_data);
/* spear300 routines */
void __init spear300_init(struct pmx_mode *pmx_mode, struct pmx_dev **pmx_devs,
diff --git a/arch/arm/mach-spear3xx/spear3xx.c
b/arch/arm/mach-spear3xx/spear3xx.c
index bc4f1c6..b1733c3 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -28,31 +28,12 @@ static struct pl061_platform_data gpio_plat_data = {
.irq_base = SPEAR3XX_GPIO_INT_BASE,
};
-struct amba_device spear3xx_gpio_device = {
- .dev = {
- .init_name = gpio,
- .platform_data = gpio_plat_data,
- },
- .res = {
- .start = SPEAR3XX_ICM3_GPIO_BASE,
- .end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
-};
+AMBA_APB_DEVICE(spear3xx_gpio, gpio, 0, SPEAR3XX_ICM3_GPIO_BASE,
+ {SPEAR3XX_IRQ_BASIC_GPIO}, gpio_plat_data);
/* uart device registration */
-struct amba_device spear3xx_uart_device = {
- .dev = {
- .init_name = uart,
- },
- .res = {
- .start = SPEAR3XX_ICM1_UART_BASE,
- .end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {SPEAR3XX_IRQ_UART},
-};
+AMBA_APB_DEVICE(spear3xx_uart, uart, 0, SPEAR3XX_ICM1_UART_BASE,
+ {SPEAR3XX_IRQ_UART}, NULL);
/* Do spear3xx familiy common initialization part here */
void __init spear3xx_init(void)
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 31/31] ARM: amba: samsung: use common amba device initializers
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-exynos/dma.c | 38 ++
arch/arm/mach-s5p64x0/dma.c | 22 +-
arch/arm/mach-s5pc100/dma.c | 38 ++
arch/arm/mach-s5pv210/dma.c | 38 ++
4 files changed, 23 insertions(+), 113 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index 8d681bf..91370de 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -74,21 +74,8 @@ struct dma_pl330_platdata exynos4_pdma0_pdata = {
.peri_id = pdma0_peri,
};
-struct amba_device exynos4_device_pdma0 = {
- .dev = {
- .init_name = dma-pl330.0,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = exynos4_pdma0_pdata,
- },
- .res = {
- .start = EXYNOS4_PA_PDMA0,
- .end = EXYNOS4_PA_PDMA0 + SZ_4K,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_PDMA0},
- .periphid = 0x00041330,
-};
+AMBA_AHB_DEVICE(exynos4_pdma0, dma-pl330.0, 0x00041330, EXYNOS4_PA_PDMA0,
+ {IRQ_PDMA0}, exynos4_pdma0_pdata);
u8 pdma1_peri[] = {
DMACH_PCM0_RX,
@@ -123,21 +110,8 @@ struct dma_pl330_platdata exynos4_pdma1_pdata = {
.peri_id = pdma1_peri,
};
-struct amba_device exynos4_device_pdma1 = {
- .dev = {
- .init_name = dma-pl330.1,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = exynos4_pdma1_pdata,
- },
- .res = {
- .start = EXYNOS4_PA_PDMA1,
- .end = EXYNOS4_PA_PDMA1 + SZ_4K,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_PDMA1},
- .periphid = 0x00041330,
-};
+AMBA_AHB_DEVICE(exynos4_pdma1, dma-pl330.1, 0x00041330, EXYNOS4_PA_PDMA1,
+ {IRQ_PDMA1}, exynos4_pdma1_pdata);
static int __init exynos4_dma_init(void)
{
@@ -146,11 +120,11 @@ static int __init exynos4_dma_init(void)
dma_cap_set(DMA_SLAVE, exynos4_pdma0_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, exynos4_pdma0_pdata.cap_mask);
- amba_device_register(exynos4_device_pdma0, iomem_resource);
+ amba_device_register(exynos4_pdma0_device, iomem_resource);
dma_cap_set(DMA_SLAVE, exynos4_pdma1_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, exynos4_pdma1_pdata.cap_mask);
- amba_device_register(exynos4_device_pdma1, iomem_resource);
+ amba_device_register(exynos4_pdma1_device, iomem_resource);
return 0;
}
diff --git a/arch/arm/mach-s5p64x0/dma.c b/arch/arm/mach-s5p64x0/dma.c
index 99049aa..f7f68ad 100644
--- a/arch/arm/mach-s5p64x0/dma.c
+++ b/arch/arm/mach-s5p64x0/dma.c
@@ -108,34 +108,22 @@ struct dma_pl330_platdata s5p6450_pdma_pdata = {
.peri_id = s5p6450_pdma_peri,
};
-struct amba_device s5p64x0_device_pdma = {
- .dev = {
- .init_name = dma-pl330,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .res = {
- .start = S5P64X0_PA_PDMA,
- .end = S5P64X0_PA_PDMA + SZ_4K,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_DMA0},
- .periphid = 0x00041330,
-};
+AMBA_AHB_DEVICE(s5p64x0_pdma, dma-pl330, 0x00041330, S5P64X0_PA_PDMA,
+ {IRQ_DMA0}, NULL);
static int __init s5p64x0_dma_init(void)
{
if (soc_is_s5p6450()) {
dma_cap_set(DMA_SLAVE, s5p6450_pdma_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, s5p6450_pdma_pdata.cap_mask);
- s5p64x0_device_pdma.dev.platform_data = s5p6450_pdma_pdata;
+ s5p64x0_pdma_device.dev.platform_data = s5p6450_pdma_pdata;
} else {
dma_cap_set(DMA_SLAVE, s5p6440_pdma_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, s5p6440_pdma_pdata.cap_mask);
- s5p64x0_device_pdma.dev.platform_data = s5p6440_pdma_pdata;
+ s5p64x0_pdma_device.dev.platform_data = s5p6440_pdma_pdata;
}
- amba_device_register(s5p64x0_device_pdma, iomem_resource);
+ amba_device_register(s5p64x0_pdma_device, iomem_resource);
return 0;
}
diff --git a/arch/arm/mach-s5pc100/dma.c b/arch/arm/mach-s5pc100/dma.c
index ac08d7e..96b1ab3 100644
--- a/arch/arm/mach-s5pc100/dma.c
+++ b/arch/arm/mach-s5pc100/dma.c
@@ -73,21 +73,8 @@ struct dma_pl330_platdata s5pc100_pdma0_pdata = {
.peri_id = pdma0_peri,
};
-struct amba_device s5pc100_device_pdma0 = {
- .dev = {
- .init_name = dma-pl330.0,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = s5pc100_pdma0_pdata,
- },
- .res = {
- .start = S5PC100_PA_PDMA0,
- .end = S5PC100_PA_PDMA0
Re: [PATCH 3/5] omap-serial: Fix the error handling in the omap_serial probe
On Friday 20 January 2012 02:19 PM, Govindraj wrote:
On Mon, Jan 16, 2012 at 3:52 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
The patch does the following
- The pm_runtime_disable is called in the remove not in the error
case of probe.The patch calls the pm_runtime_disable in the error
case.
- The up is not freed in the error path. Fix the memory leak by calling
kfree in the error path.
- Also the iounmap is not called fix the same by calling iounmap in the
error case of probe and remove .
- Make the name of the error tags more meaningful.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/tty/serial/omap-serial.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 1c24269..8c6f137 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1369,14 +1369,14 @@ static int serial_omap_probe(struct platform_device
*pdev)
dma_rx = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
if (!dma_rx) {
- ret = -EINVAL;
- goto err;
+ ret = -ENXIO;
+ goto do_release_region;
}
dma_tx = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
if (!dma_tx) {
- ret = -EINVAL;
- goto err;
+ ret = -ENXIO;
+ goto do_release_region;
}
up = kzalloc(sizeof(*up), GFP_KERNEL);
@@ -1403,7 +1403,7 @@ static int serial_omap_probe(struct platform_device
*pdev)
dev_err(pdev-dev, failed to get alias/pdev id, errno %d\n,
up-port.line);
ret = -ENODEV;
- goto err;
+ goto err_port_line;
}
sprintf(up-name, OMAP UART%d, up-port.line);
@@ -1412,7 +1412,7 @@ static int serial_omap_probe(struct platform_device
*pdev)
if (!up-port.membase) {
dev_err(pdev-dev, can't ioremap UART\n);
ret = -ENOMEM;
- goto err;
+ goto err_ioremap;
}
up-port.flags = omap_up_info-flags;
@@ -1458,16 +1458,22 @@ static int serial_omap_probe(struct platform_device
*pdev)
ret = uart_add_one_port(serial_omap_reg, up-port);
if (ret != 0)
- goto do_release_region;
+ goto err_add_port;
pm_runtime_put(pdev-dev);
platform_set_drvdata(pdev, up);
return 0;
-err:
- dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
- pdev-id, __func__, ret);
+
+err_add_port:
+ pm_runtime_disable(pdev-dev);
+ iounmap(up-port.membase);
+err_ioremap:
+err_port_line:
+ kfree(up);
do_release_region:
release_mem_region(mem-start, resource_size(mem));
+ dev_err(pdev-dev, [UART%d]: failure [%s]: %d\n,
+ pdev-id, __func__, ret);
return ret;
}
@@ -1476,6 +1482,7 @@ static int serial_omap_remove(struct platform_device
*dev)
struct uart_omap_port *up = platform_get_drvdata(dev);
if (up) {
+ iounmap(up-port.membase);
you can build omap-serial as module insmod and rmmod
the module and test this patch.
This can be done on zoom board which uses a non-omap uart
as console.
Yes will do that and post another version.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 30/31] ARM: amba: spear: use common amba device initializers
On 1/20/2012 3:02 PM, Russell King - ARM Linux wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-spear3xx/spear300.c | 14 ++
arch/arm/mach-spear3xx/spear3xx.c | 27 ---
2 files changed, 6 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-spear3xx/spear300.c
b/arch/arm/mach-spear3xx/spear300.c
index 6fdeec9..9da50e281 100644
--- a/arch/arm/mach-spear3xx/spear300.c
+++ b/arch/arm/mach-spear3xx/spear300.c
@@ -430,18 +430,8 @@ static struct pl061_platform_data gpio1_plat_data = {
.irq_base = SPEAR300_GPIO1_INT_BASE,
};
-struct amba_device spear300_gpio1_device = {
- .dev = {
- .init_name = gpio1,
- .platform_data = gpio1_plat_data,
- },
- .res = {
- .start = SPEAR300_GPIO_BASE,
- .end = SPEAR300_GPIO_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {SPEAR300_VIRQ_GPIO1},
-};
+AMBA_APB_DEVICE(spear300_gpio1, gpio1, 0, SPEAR300_GPIO_BASE,
+ {SPEAR300_VIRQ_GPIO1}, gpio1_plat_data);
/* spear300 routines */
void __init spear300_init(struct pmx_mode *pmx_mode, struct pmx_dev
**pmx_devs,
diff --git a/arch/arm/mach-spear3xx/spear3xx.c
b/arch/arm/mach-spear3xx/spear3xx.c
index bc4f1c6..b1733c3 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -28,31 +28,12 @@ static struct pl061_platform_data gpio_plat_data = {
.irq_base = SPEAR3XX_GPIO_INT_BASE,
};
-struct amba_device spear3xx_gpio_device = {
- .dev = {
- .init_name = gpio,
- .platform_data = gpio_plat_data,
- },
- .res = {
- .start = SPEAR3XX_ICM3_GPIO_BASE,
- .end = SPEAR3XX_ICM3_GPIO_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {SPEAR3XX_IRQ_BASIC_GPIO},
-};
+AMBA_APB_DEVICE(spear3xx_gpio, gpio, 0, SPEAR3XX_ICM3_GPIO_BASE,
+ {SPEAR3XX_IRQ_BASIC_GPIO}, gpio_plat_data);
/* uart device registration */
-struct amba_device spear3xx_uart_device = {
- .dev = {
- .init_name = uart,
- },
- .res = {
- .start = SPEAR3XX_ICM1_UART_BASE,
- .end = SPEAR3XX_ICM1_UART_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .irq = {SPEAR3XX_IRQ_UART},
-};
+AMBA_APB_DEVICE(spear3xx_uart, uart, 0, SPEAR3XX_ICM1_UART_BASE,
+ {SPEAR3XX_IRQ_UART}, NULL);
/* Do spear3xx familiy common initialization part here */
void __init spear3xx_init(void)
Acked-by: Viresh Kumar viresh.ku...@st.com
--
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4 hwmod problem when unloading omapdss
Hi Benoit, I see the below WARNING on v3.3-rc1, running on OMAP4460 Panda, when I unload the DSS modules. This didn't happen on v3.2, or linux-next from a few weeks ago. Tomi [ 29.667572] [ cut here ] [ 29.667572] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1604 _idle+0x164/0x17c() [ 29.674774] omap_hwmod: dss_hdmi: idle state can only be entered from enabled state [ 29.688293] Modules linked in: cfbimgblt cfbfillrect cfbcopyarea omapdss(-) [last unloaded: panel _dvi] [ 29.693084] [c001b614] (unwind_backtrace+0x0/0xf0) from [c0041d70] (warn_slowpath_common+0x4c /0x64) [ 29.703918] [c0041d70] (warn_slowpath_common+0x4c/0x64) from [c0041e1c] (warn_slowpath_fmt+0x 30/0x40) [ 29.717987] [c0041e1c] (warn_slowpath_fmt+0x30/0x40) from [c0027fdc] (_idle+0x164/0x17c) [ 29.724670] [c0027fdc] (_idle+0x164/0x17c) from [c0028850] (omap_hwmod_idle+0x24/0x40) [ 29.729461] [c0028850] (omap_hwmod_idle+0x24/0x40) from [c003b670] (omap_device_idle_hwmods+0 x24/0x3c) [ 29.745086] [c003b670] (omap_device_idle_hwmods+0x24/0x3c) from [c003b860] (_omap_device_deac tivate+0x9c/0x138) [ 29.745086] [c003b860] (_omap_device_deactivate+0x9c/0x138) from [c003c270] (omap_device_idle +0x28/0x54) [ 29.745086] [c003c270] (omap_device_idle+0x28/0x54) from [c003c2b8] (_od_runtime_suspend+0x1c /0x24) [ 29.776672] [c003c2b8] (_od_runtime_suspend+0x1c/0x24) from [c02b5a68] (__rpm_callback+0x70/0 x98) [ 29.786346] [c02b5a68] (__rpm_callback+0x70/0x98) from [c02b5f08] (rpm_suspend+0x240/0x6c0) [ 29.786346] [c02b5f08] (rpm_suspend+0x240/0x6c0) from [c02b734c] (__pm_runtime_suspend+0x5c/0 x74) [ 29.799774] [c02b734c] (__pm_runtime_suspend+0x5c/0x74) from [c02b2ec4] (pm_generic_runtime_i dle+0x44/0x4c) [ 29.807586] [c02b2ec4] (pm_generic_runtime_idle+0x44/0x4c) from [c02b5a68] (__rpm_callback+0x 70/0x98) [ 29.807586] [c02b5a68] (__rpm_callback+0x70/0x98) from [c02b64fc] (rpm_idle+0x100/0x228) [ 29.831085] [c02b64fc] (rpm_idle+0x100/0x228) from [c02b66f4] (__pm_runtime_idle+0x5c/0x74) [ 29.843658] [c02b66f4] (__pm_runtime_idle+0x5c/0x74) from [c02ae6a4] (__device_release_driver +0x50/0xc0) [ 29.846649] [c02ae6a4] (__device_release_driver+0x50/0xc0) from [c02aed0c] (driver_detach+0xb 4/0xb8) [ 29.863891] [c02aed0c] (driver_detach+0xb4/0xb8) from [c02ae580] (bus_remove_driver+0x7c/0xc0 ) [ 29.870086] [c02ae580] (bus_remove_driver+0x7c/0xc0) from [bff0] (omap_dss_remove+0x14/0x 6c [omapdss]) [ 29.877929] [bff0] (omap_dss_remove+0x14/0x6c [omapdss]) from [c02afe60] (platform_drv_re move+0x18/0x1c) [ 29.893463] [c02afe60] (platform_drv_remove+0x18/0x1c) from [c02ae6c4] (__device_release_driv er+0x70/0xc0) [ 29.901489] [c02ae6c4] (__device_release_driver+0x70/0xc0) from [c02aed0c] (driver_detach+0xb 4/0xb8) [ 29.901489] [c02aed0c] (driver_detach+0xb4/0xb8) from [c02ae580] (bus_remove_driver+0x7c/0xc0 ) [ 29.924499] [c02ae580] (bus_remove_driver+0x7c/0xc0) from [bf020e98] (omap_dss_exit+0x48/0x58 [omapdss]) [ 29.932586] [bf020e98] (omap_dss_exit+0x48/0x58 [omapdss]) from [c0098f54] (sys_delete_module +0x164/0x254) [ 29.940399] [c0098f54] (sys_delete_module+0x164/0x254) from [c0013c80] (ret_fast_syscall+0x0/ 0x3c) [ 29.955139] ---[ end trace 52be023ca95d7e20 ]--- signature.asc Description: This is a digitally signed message part
PM(?) problems on v3.3-rc1 on OMAP3
Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. Second, I compile DSS as modules, and don't load them. Looking at debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are increasing. What is making DSS powerdomain switch back and forth? Third, when I load the DSS modules, I see only ON state increasing for dss_pwrdm, as it should be. However, I'm getting constant stream of sync losts from DSS, and the display doesn't basically work at all. I can see MPU pwrdm going into RET a lot, and if I do while true; do echo foo; done, which I presume basically prevents RET for MPU, the display becomes stable. This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2 broken?), although this is happening all the time. In this case, as in Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for DSS fclk on OPP2. And I'm not aware of any other constraints for DSS (well, memory throughput, but that should cause fifo underflows). Is there a way to lock the OPP to the full power OPP? Is there a way to see the OPP being used? Tomi signature.asc Description: This is a digitally signed message part
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. can you try enabling CONFIG_CPU_IDLE ? Second, I compile DSS as modules, and don't load them. Looking at debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are increasing. What is making DSS powerdomain switch back and forth? Third, when I load the DSS modules, I see only ON state increasing for dss_pwrdm, as it should be. However, I'm getting constant stream of sync losts from DSS, and the display doesn't basically work at all. I can see MPU pwrdm going into RET a lot, and if I do while true; do echo foo; done, which I presume basically prevents RET for MPU, the display becomes stable. This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2 broken?), although this is happening all the time. In this case, as in Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for DSS fclk on OPP2. And I'm not aware of any other constraints for DSS (well, memory throughput, but that should cause fifo underflows). Is there a way to lock the OPP to the full power OPP? Is there a way to see the OPP being used? Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. can you try enabling CONFIG_CPU_IDLE ? Enabling CPU_IDLE does remove the problems. I don't know what it's supposed to do, but it seems to keep the MPU and DSS in ON state all the time, so the problem disappears. Tomi signature.asc Description: This is a digitally signed message part
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. can you try enabling CONFIG_CPU_IDLE ? Enabling CPU_IDLE does remove the problems. I don't know what it's supposed to do, but it seems to keep the MPU and DSS in ON state all the time, so the problem disappears. 3.3-rc1 has uart runtime patches merged we have removed uart dependency for system to enter low powers states and used pm_qos calls, but pm_qos api's seem do get activated only by enabling config_cpu_idle. Question to kevin/Paul, Shouldn't system be doing wfi if cpu_idle is not enabled ? since we are mapping omap3_pm_idle to pm_idle thread system enters low power states even if config_cpu_idle is not enabled. Is this expected behavior? -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. Second, I compile DSS as modules, and don't load them. Looking at debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are increasing. What is making DSS powerdomain switch back and forth? Third, when I load the DSS modules, I see only ON state increasing for dss_pwrdm, as it should be. However, I'm getting constant stream of sync losts from DSS, and the display doesn't basically work at all. I can see MPU pwrdm going into RET a lot, and if I do while true; do echo foo; done, which I presume basically prevents RET for MPU, the display becomes stable. This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2 broken?), although this is happening all the time. In this case, as in Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for DSS fclk on OPP2. And I'm not aware of any other constraints for DSS (well, memory throughput, but that should cause fifo underflows). Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. failure logs as in here [1]. I was using latest mainline and beagle -XM -- Thanks, Govindraj.R [1]: http://pastebin.com/9ZfB2V6B -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. I thought so too, and tried it but got the same crash as you. However, I'd imagine that if I don't enable CPU idle or the governors, the board would stay in full power mode always. But this doesn't seem to be the case. Then again, I don't see how CPU power management could affect the DSS directly. So it's probably something like: cpu goes to RET - something else is allowed go to lower power state (L3?) - DSS breaks. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 05/31] ARM: amba: mxs: convert to use amba_device_alloc
On Fri, Jan 20, 2012 at 09:24:05AM +, Russell King - ARM Linux wrote:
Convert MXS to use the new amba_device_alloc APIs.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-mxs/devices.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mxs/devices.c b/arch/arm/mach-mxs/devices.c
index fe3e847..052d8dd 100644
--- a/arch/arm/mach-mxs/devices.c
+++ b/arch/arm/mach-mxs/devices.c
@@ -77,16 +77,18 @@ struct platform_device *__init
mxs_add_platform_device_dmamask(
int __init mxs_add_amba_device(const struct amba_device *dev)
{
- struct amba_device *adev = kmalloc(sizeof(*adev), GFP_KERNEL);
+ struct amba_device *adev = amba_device_alloc(dev-init_name,
The 'dev-init_name' needs to be 'dev-dev.init_name'. Otherwise, we
see the compile error below.
CC arch/arm/mach-mxs/devices.o
arch/arm/mach-mxs/devices.c: In function ‘mxs_add_amba_device’:
arch/arm/mach-mxs/devices.c:80:50: error: ‘const struct amba_device’ has no
member named ‘init_name’
Other than that,
Acked-by: Shawn Guo shawn@linaro.org
Regards,
Shawn
+ dev-res.start, resource_size(dev-res));
if (!adev) {
pr_err(%s: failed to allocate memory, __func__);
return -ENOMEM;
}
- *adev = *dev;
+ adev-irq[0] = dev-irq[0];
+ adev-irq[1] = dev-irq[1];
- return amba_device_register(adev, iomem_resource);
+ return amba_device_add(adev, iomem_resource);
}
struct device mxs_apbh_bus = {
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/31] ARM: amba: mxs: get rid of NO_IRQ initializers
On Fri, Jan 20, 2012 at 09:26:28AM +, Russell King - ARM Linux wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Shawn Guo shawn@linaro.org
---
arch/arm/mach-mxs/devices/amba-duart.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mxs/devices/amba-duart.c
b/arch/arm/mach-mxs/devices/amba-duart.c
index a559db0..a5479f7 100644
--- a/arch/arm/mach-mxs/devices/amba-duart.c
+++ b/arch/arm/mach-mxs/devices/amba-duart.c
@@ -23,7 +23,7 @@ const struct amba_device name##_device __initconst = {
\
.end = (soc ## _DUART_BASE_ADDR) + SZ_8K - 1, \
.flags = IORESOURCE_MEM,\
}, \
- .irq = {soc ## _INT_DUART, NO_IRQ}, \
+ .irq = {soc ## _INT_DUART}, \
}
#ifdef CONFIG_SOC_IMX23
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
Govindraj, On Fri, Jan 20, 2012 at 12:21 PM, Govindraj govindraj...@gmail.com wrote: On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. can you try enabling CONFIG_CPU_IDLE ? Enabling CPU_IDLE does remove the problems. I don't know what it's supposed to do, but it seems to keep the MPU and DSS in ON state all the time, so the problem disappears. 3.3-rc1 has uart runtime patches merged we have removed uart dependency for system to enter low powers states and used pm_qos calls, but pm_qos api's seem do get activated only by enabling config_cpu_idle. Question to kevin/Paul, Shouldn't system be doing wfi if cpu_idle is not enabled ? since we are mapping omap3_pm_idle to pm_idle thread system enters low power states even if config_cpu_idle is not enabled. Is this expected behavior? Yes the wfi instruction gets executed in all cases. However with CPU_IDLE enabled a valid C-state is selected, depending on the requested PM QoS constraints. Then the MPU and CORE next power states are programmed accordingly. Cf. code in arch/arm/mach-omap2/cpuidle34xx.c which is conditionally compiled on the CPU_IDLE option. Jean -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
Tomi, On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. I thought so too, and tried it but got the same crash as you. However, I'd imagine that if I don't enable CPU idle or the governors, the board would stay in full power mode always. But this doesn't seem to be the case. Then again, I don't see how CPU power management could affect the DSS directly. So it's probably something like: cpu goes to RET - something else is allowed go to lower power state (L3?) - DSS breaks. It is probably related to the CORE state. Can you check if CORE goes to low power mode when CPU_IDLE is enabled? To prevent the CORE from going into a too-low power mode you need to request a PM QoS constraint, as Govindraj explained here above. Hope this helps! Jean Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/31] ARM: amba: mxs: convert to use amba_device_alloc
On Fri, Jan 20, 2012 at 08:25:39PM +0800, Shawn Guo wrote:
On Fri, Jan 20, 2012 at 09:24:05AM +, Russell King - ARM Linux wrote:
Convert MXS to use the new amba_device_alloc APIs.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-mxs/devices.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mxs/devices.c b/arch/arm/mach-mxs/devices.c
index fe3e847..052d8dd 100644
--- a/arch/arm/mach-mxs/devices.c
+++ b/arch/arm/mach-mxs/devices.c
@@ -77,16 +77,18 @@ struct platform_device *__init
mxs_add_platform_device_dmamask(
int __init mxs_add_amba_device(const struct amba_device *dev)
{
- struct amba_device *adev = kmalloc(sizeof(*adev), GFP_KERNEL);
+ struct amba_device *adev = amba_device_alloc(dev-init_name,
The 'dev-init_name' needs to be 'dev-dev.init_name'. Otherwise, we
see the compile error below.
Good catch, fixed, and ack added, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote: Tomi, On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. I thought so too, and tried it but got the same crash as you. However, I'd imagine that if I don't enable CPU idle or the governors, the board would stay in full power mode always. But this doesn't seem to be the case. Then again, I don't see how CPU power management could affect the DSS directly. So it's probably something like: cpu goes to RET - something else is allowed go to lower power state (L3?) - DSS breaks. It is probably related to the CORE state. Can you check if CORE goes to low power mode when CPU_IDLE is enabled? This is without CPU_IDLE, i.e. when I'm having problems: # cat /debug/pm_debug/count |grep -i core core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 According to that, core is always on. To prevent the CORE from going into a too-low power mode you need to request a PM QoS constraint, as Govindraj explained here above. What different power modes there are? With the clock configs I'm using (small display, low clock rates), both OPP100 and OPP50 should work fine. Tomi signature.asc Description: This is a digitally signed message part
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, Jan 20, 2012 at 6:02 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Govindraj, On Fri, Jan 20, 2012 at 12:21 PM, Govindraj govindraj...@gmail.com wrote: On Fri, Jan 20, 2012 at 4:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. can you try enabling CONFIG_CPU_IDLE ? Enabling CPU_IDLE does remove the problems. I don't know what it's supposed to do, but it seems to keep the MPU and DSS in ON state all the time, so the problem disappears. 3.3-rc1 has uart runtime patches merged we have removed uart dependency for system to enter low powers states and used pm_qos calls, but pm_qos api's seem do get activated only by enabling config_cpu_idle. Question to kevin/Paul, Shouldn't system be doing wfi if cpu_idle is not enabled ? since we are mapping omap3_pm_idle to pm_idle thread system enters low power states even if config_cpu_idle is not enabled. Is this expected behavior? Yes the wfi instruction gets executed in all cases. However with CPU_IDLE enabled a valid C-state is selected, depending on the requested PM QoS constraints. Then the MPU and CORE next power states are programmed accordingly. okay, but if cpuidle is not selected shouldn't it prevent system from going to low power state. -- Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, Jan 20, 2012 at 5:31 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. I thought so too, and tried it but got the same crash as you. However, I'd imagine that if I don't enable CPU idle or the governors, the board would stay in full power mode always. But this doesn't seem to be the case. AFAIK if we are not using cpuidle/governors then opp value will be retained from what the bootloader configures it. However I am not sure whether bootloader will set it in highest opp. Still trying to find a way to know it. Then again, I don't see how CPU power management could affect the DSS directly. So it's probably something like: cpu goes to RET - something else is allowed go to lower power state (L3?) - DSS breaks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Friday 20 January 2012 05:26 PM, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. Second, I compile DSS as modules, and don't load them. Looking at debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are increasing. What is making DSS powerdomain switch back and forth? Third, when I load the DSS modules, I see only ON state increasing for dss_pwrdm, as it should be. However, I'm getting constant stream of sync losts from DSS, and the display doesn't basically work at all. I can see MPU pwrdm going into RET a lot, and if I do while true; do echo foo; done, which I presume basically prevents RET for MPU, the display becomes stable. This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2 broken?), although this is happening all the time. In this case, as in Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for DSS fclk on OPP2. And I'm not aware of any other constraints for DSS (well, memory throughput, but that should cause fifo underflows). Is there a way to lock the OPP to the full power OPP? The other way could be to use userspace governor and set it manually. Also the governor could be changed through sysfs. btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. failure logs as in here [1]. I was using latest mainline and beagle -XM -- Thanks, Govindraj.R [1]: http://pastebin.com/9ZfB2V6B -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
Tomi, On Fri, Jan 20, 2012 at 1:40 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote: Tomi, On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. I thought so too, and tried it but got the same crash as you. However, I'd imagine that if I don't enable CPU idle or the governors, the board would stay in full power mode always. But this doesn't seem to be the case. Then again, I don't see how CPU power management could affect the DSS directly. So it's probably something like: cpu goes to RET - something else is allowed go to lower power state (L3?) - DSS breaks. It is probably related to the CORE state. Can you check if CORE goes to low power mode when CPU_IDLE is enabled? This is without CPU_IDLE, i.e. when I'm having problems: # cat /debug/pm_debug/count |grep -i core core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 According to that, core is always on. To prevent the CORE from going into a too-low power mode you need to request a PM QoS constraint, as Govindraj explained here above. What different power modes there are? With the clock configs I'm using (small display, low clock rates), both OPP100 and OPP50 should work fine. CPU_IDLE is not about the OPP (i.e. frequencies), it is about the power domains states (ON, RET ...). Without CPU_IDLE enabled the power domains will try to transition to the default power states (programmed in the PRCM registers). By default all power states are programmed to RET or OFF. In all cases CPU_IDLE should be enabled to ensure the proper interaction between the cpuidle and PM QoS frameworks. You can try the following in order to isolate the problem: 1. check if the CORE and DSS are hitting a low power state. The MPU state should not have a direct impact on the DSS; the CORE state has a direct effect on DSS since it drives the memory controller, 2. use a fixed frequency for the MPU, by enabling the userspace or the performance cpufreq governor. This should rule out an MPU performance problem. Tomi Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Started afresh from:
90a4c0f uml: fix compile for x86-64
And added 3, 4, 5, 6:
603c316 arm: omap4: pmu: support runtime pm
4899fbd arm: omap4: support pmu
d737bb1 arm: omap4: create pmu device via hwmod
4e0259e arm: omap4: hwmod: introduce emu hwmod
Still no interrupts firing. I am using your .config file.
My HW:
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part: 0xc09
CPU revision: 2
Hardware: OMAP4 Panda board
Revision: 0020
There must be something I am missing here.
On Thu, Jan 19, 2012 at 6:07 PM, stephane eranian
eran...@googlemail.com wrote:
Just did a fresh clone of Linus' tree:
$ git log --oneline | fgrep 'allow platform specific'
e0516a6 arm: pmu: allow platform specific irq enable/disable handling
$ git log --oneline | fgrep 'cross trigger'
14eec97 arm: introduce cross trigger interface helpers
Unless you were referring to a different pair of patches.
On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei ming@canonical.com wrote:
On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
eran...@googlemail.com wrote:
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei ming@canonical.com wrote:
Hi,
On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
eran...@googlemail.com wrote:
Hi,
Ok some update on this.
With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a
kernel that
You forget patch 1 and patch 2?
They are already in 3.2.0. Unless I am mistaken.
Sorry, I just found that they have been merged to 3.2.
After a double check, the two patches are not merged to 3.2, but have
been merged to the latest linus tree and can be seen in 3.3-rc1.
Also the commit 3c50729b(ARM: OMAP4: PM: Initialise all the clockdomains
to supported states) has been merged to linus tree too.
So if you just tested the latest linus tree simply, you need to apply
the patch[1]
(I have mentioned the problem in the thread.)
Changing LMO, u-boot.bin did not help. Even with perf top I get no
interrupts.
My Linus tree is at commit fa1952b:
[6] 11891e1 arm: omap4: pmu: support runtime pm
[5] 25fab8a arm: omap4: support pmu
[4] fddef77 arm: omap4: create pmu device via hwmod
fa1952b ARM: OMAP4: hwmod data: Add support for the debug modules
Sorry, there is no commit fa1952b in linus[1] tree at all, so you are
not testing
linus tree...
If you'd like to follow my instructions, I can help you further.
ccb19d2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
c3b5003 tg3: Fix single-vector MSI-X code
I think [1] had conflicts when applying it to the tree.
It is only one line(one character) change, you can do it manually.
thanks,
--
Ming Lei
[1],
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index 9299ac2..41d2260 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
.prcm_partition = OMAP4430_PRM_PARTITION,
.cm_inst = OMAP4430_PRM_EMU_CM_INST,
.clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
- .flags = CLKDM_CAN_HWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
[1], http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/31] ARM: amba: of: convert to use amba_device_alloc
On 01/20/2012 03:23 AM, Russell King - ARM Linux wrote: Convert DT code to use the new amba_device_alloc APIs. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Rob Herring rob.herr...@calxeda.com --- drivers/of/platform.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 63b3ec4..cae9477 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -253,7 +253,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node, if (!of_device_is_available(node)) return NULL; - dev = kzalloc(sizeof(*dev), GFP_KERNEL); + dev = amba_device_alloc(NULL, 0, 0); if (!dev) return NULL; @@ -283,14 +283,14 @@ static struct amba_device *of_amba_device_create(struct device_node *node, if (ret) goto err_free; - ret = amba_device_register(dev, iomem_resource); + ret = amba_device_add(dev, iomem_resource); if (ret) goto err_free; return dev; err_free: - kfree(dev); + amba_device_put(dev); return NULL; } #else /* CONFIG_ARM_AMBA */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 23/31] ARM: amba: omap2: use common amba device initializers
* Russell King - ARM Linux li...@arm.linux.org.uk [120120 00:58]:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/emu.c | 26 ++
1 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/emu.c b/arch/arm/mach-omap2/emu.c
index 9c442e2..ce91aad 100644
--- a/arch/arm/mach-omap2/emu.c
+++ b/arch/arm/mach-omap2/emu.c
@@ -30,29 +30,8 @@ MODULE_AUTHOR(Alexander Shishkin);
#define ETB_BASE (L4_EMU_34XX_PHYS + 0x1b000)
#define DAPCTL (L4_EMU_34XX_PHYS + 0x1d000)
-static struct amba_device omap3_etb_device = {
- .dev= {
- .init_name = etb,
- },
- .res= {
- .start = ETB_BASE,
- .end= ETB_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .periphid = 0x000bb907,
-};
-
-static struct amba_device omap3_etm_device = {
- .dev= {
- .init_name = etm,
- },
- .res= {
- .start = ETM_BASE,
- .end= ETM_BASE + SZ_4K - 1,
- .flags = IORESOURCE_MEM,
- },
- .periphid = 0x102bb921,
-};
+static AMBA_APB_DEVICE(omap3_etb, etb, 0x000bb907, ETB_BASE, { }, NULL);
+static AMBA_APB_DEVICE(omap3_etm, etm, 0x102bb921, ETM_BASE, { }, NULL);
static int __init emu_init(void)
{
@@ -66,4 +45,3 @@ static int __init emu_init(void)
}
subsys_initcall(emu_init);
-
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAPDSS: HDMI PHY burnout fix
* Tomi Valkeinen tomi.valkei...@ti.com [120117 04:16]: The main patch in this set is the last one, which implements a fix for the HW bug on OMAP4 which causes physical damage to the board if the HDMI cable is not connected but HDMI output is enabled. The preceding patches are small cleanups/fixes for HDMI GPIOs so that the fix can be implemented. Note that I haven't gotten a confirmation that using LDO_ON for the HDMI PHY power fixes the issue. So whether the fix works or not is unclear. Feel free to merge via fb tree. For the arch/arm/*omap*/* parts: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 2012-01-20 at 14:36 +0100, Jean Pihet wrote: Tomi, On Fri, Jan 20, 2012 at 1:40 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 13:34 +0100, Jean Pihet wrote: Tomi, On Fri, Jan 20, 2012 at 1:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Fri, 2012-01-20 at 17:26 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Is there a way to lock the OPP to the full power OPP? btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. I thought so too, and tried it but got the same crash as you. However, I'd imagine that if I don't enable CPU idle or the governors, the board would stay in full power mode always. But this doesn't seem to be the case. Then again, I don't see how CPU power management could affect the DSS directly. So it's probably something like: cpu goes to RET - something else is allowed go to lower power state (L3?) - DSS breaks. It is probably related to the CORE state. Can you check if CORE goes to low power mode when CPU_IDLE is enabled? This is without CPU_IDLE, i.e. when I'm having problems: # cat /debug/pm_debug/count |grep -i core core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 According to that, core is always on. To prevent the CORE from going into a too-low power mode you need to request a PM QoS constraint, as Govindraj explained here above. What different power modes there are? With the clock configs I'm using (small display, low clock rates), both OPP100 and OPP50 should work fine. CPU_IDLE is not about the OPP (i.e. frequencies), it is about the power domains states (ON, RET ...). Without CPU_IDLE enabled the power domains will try to transition to the default power states (programmed in the PRCM registers). By default all power states are programmed to RET or OFF. In all cases CPU_IDLE should be enabled to ensure the proper interaction between the cpuidle and PM QoS frameworks. Hmm, So CPU_IDLE is also about other power domains than mpu? What does it do? The CONFIG_CPU_IDLE help text doesn't say much. And I'm still confused about why it would be needed. If I enable DSS, that should enable and keep dss powerdomain in ON state, and the pm/hwmod framework (or something =) should also enable core when DSS is enabled. And with low func clock frequencies DSS should operate in all OPPs. So everything should be in order, with or without CPU_IDLE, right? Or does core go to sleep even if DSS is enabled? But then again, pm_debug/count shows that core is always ON. You can try the following in order to isolate the problem: 1. check if the CORE and DSS are hitting a low power state. The MPU state should not have a direct impact on the DSS; the CORE state has a direct effect on DSS since it drives the memory controller, According to pm_debug/count file, core and dss are ON. 2. use a fixed frequency for the MPU, by enabling the userspace or the performance cpufreq governor. This should rule out an MPU performance problem. Yep. But that'll have to wait until enabling cpufreq doesn't crash the kernel. But I can't see how MPU could affect DSS, as after DSS is enabled, the MPU doesn't do anything about it. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] i2c: OMAP: Fix OMAP1 build error
CONFIG_OF is not defined for OMAP1 yet and thus the omap1_defconfig build
generate an error for 3.3-rc1.
drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
drivers/i2c/busses/i2c-omap.c:1021:26: error: 'omap_i2c_of_match' undeclared
(first use in this function)
drivers/i2c/busses/i2c-omap.c:1021:26: note: each undeclared identifier is
reported only once for each function it appears in
Wrap omap_i2c_of_match with of_match_ptr() to prevent compilation error in case
of OMAP1 build.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..801df60 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1018,7 +1018,7 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
- match = of_match_device(omap_i2c_of_match, pdev-dev);
+ match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
if (match) {
u32 freq = 10; /* default to 10 Hz */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: OMAP: Fix OMAP1 build error
* Cousson, Benoit b-cous...@ti.com [120120 07:22]:
CONFIG_OF is not defined for OMAP1 yet and thus the omap1_defconfig build
generate an error for 3.3-rc1.
drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
drivers/i2c/busses/i2c-omap.c:1021:26: error: 'omap_i2c_of_match' undeclared
(first use in this function)
drivers/i2c/busses/i2c-omap.c:1021:26: note: each undeclared identifier is
reported only once for each function it appears in
Wrap omap_i2c_of_match with of_match_ptr() to prevent compilation error in
case of OMAP1 build.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Ben Dooks ben-li...@fluff.org
Thanks, Ben care to ack this one? I'd like to apply it into
my fixes branch so I can compile and boot test all the
following fixes without having to apply this fix every
time I compile ;)
Regards,
Tony
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..801df60 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1018,7 +1018,7 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
- match = of_match_device(omap_i2c_of_match, pdev-dev);
+ match = of_match_device(of_match_ptr(omap_i2c_of_match), pdev-dev);
if (match) {
u32 freq = 10; /* default to 10 Hz */
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPMC: fix device size setup
* Yegor Yefremov yegor_s...@visionsystems.de [120120 07:29]: following statement can only change device size from 8-bit(0) to 16-bit(1), but not vice versa: regval |= GPMC_CONFIG1_DEVICESIZE(wval); so as this field has 1 reserved bit, that could be used in future, just clear both bits and then OR with the desired value Looks like a valid fix to me. Care to repost it with linux-arm-kernel mailing list also Cc'd so I can apply it into my fixes branch? Thanks, Tony Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/mach-omap2/gpmc.c |6 ++ 1 file changed, 6 insertions(+) Index: b/arch/arm/mach-omap2/gpmc.c === --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -528,7 +528,13 @@ case GPMC_CONFIG_DEV_SIZE: regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); + + /* clear 2 target bits */ + regval = ~GPMC_CONFIG1_DEVICESIZE(3); + + /* set the proper value */ regval |= GPMC_CONFIG1_DEVICESIZE(wval); + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval); break; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
GPMC: fix device size setup
following statement can only change device size from 8-bit(0) to 16-bit(1), but not vice versa: regval |= GPMC_CONFIG1_DEVICESIZE(wval); so as this field has 1 reserved bit, that could be used in future, just clear both bits and then OR with the desired value Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/mach-omap2/gpmc.c |6 ++ 1 file changed, 6 insertions(+) Index: b/arch/arm/mach-omap2/gpmc.c === --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -528,7 +528,13 @@ case GPMC_CONFIG_DEV_SIZE: regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); + + /* clear 2 target bits */ + regval = ~GPMC_CONFIG1_DEVICESIZE(3); + + /* set the proper value */ regval |= GPMC_CONFIG1_DEVICESIZE(wval); + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval); break; -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 24/31] ARM: amba: ep93xx: use common amba device initializers
On Friday, January 20, 2012 2:31 AM, Russell King wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-ep93xx/core.c | 46 +- 1 files changed, 6 insertions(+), 40 deletions(-) Acked-by: H Hartley Sweeten hswee...@visionengravers.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setup
Hi Tony,
Would be nice to have this for -rc as this used to work several
releases back when hsmmc23_before_set_reg() was checking for a
regulator, which wasn't set for MMC3 so the function would return
early, not causing the problem it causes now.
On Sun, Dec 18, 2011 at 2:35 AM, Grazvydas Ignotas nota...@gmail.com wrote:
hsmmc23_before_set_reg() can set MMCSDIO2ADPCLKISEL bit, which
enables internal clock for MMC2. Currently this function is also called
by code handling MMC3, and if .internal_clock is set in platform data
(by default it currently is), it will set MMCSDIO2ADPCLKISEL for MMC2
instead of MMC3 (MMC3 doesn't have such bit so nothing actually needs to
be done). This breaks 2nd SD slot on pandora.
Fix this by changing hsmmc23_before_set_reg() to only handle MMC2.
Note that this removes .remux() call for MMC3, but no board currently
needs it and it's also not called for MMC4 and MMC5.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
applies both on mainline and hsmmc branch.
arch/arm/mach-omap2/hsmmc.c | 7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f4a1020..d90ac08 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -171,7 +171,7 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
}
}
-static void hsmmc23_before_set_reg(struct device *dev, int slot,
+static void hsmmc2_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
struct omap_mmc_platform_data *mmc = dev-platform_data;
@@ -378,14 +378,13 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
c-caps = ~MMC_CAP_8_BIT_DATA;
c-caps |= MMC_CAP_4_BIT_DATA;
}
- /* FALLTHROUGH */
- case 3:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
/* off-chip level shifting, or none */
- mmc-slots[0].before_set_reg = hsmmc23_before_set_reg;
+ mmc-slots[0].before_set_reg = hsmmc2_before_set_reg;
mmc-slots[0].after_set_reg = NULL;
}
break;
+ case 3:
case 4:
case 5:
mmc-slots[0].before_set_reg = NULL;
--
1.7.0.4
--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setup
* Grazvydas Ignotas nota...@gmail.com [120120 08:51]: Hi Tony, Would be nice to have this for -rc as this used to work several releases back when hsmmc23_before_set_reg() was checking for a regulator, which wasn't set for MMC3 so the function would return early, not causing the problem it causes now. Yeah this looks like a fix. I'll take a look next week as I'll be travelling. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 18/31] ARM: amba: provide common initializers for static amba devices
On Friday, January 20, 2012 2:29 AM, Russell King wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- include/linux/amba/bus.h | 33 + 1 files changed, 33 insertions(+), 0 deletions(-) Acked-by: H Hartley Sweeten hswee...@visionengravers.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2/PM on 3.2 broken?
Tomi Valkeinen tomi.valkei...@ti.com writes: On Thu, 2012-01-19 at 11:24 -0800, Kevin Hilman wrote: Tomi Valkeinen tomi.valkei...@ti.com writes: Now, you already said using pm_runtime_put_sync version is the correct way when suspending. But to use that I need to either always use pm_runtime_put_sync, or add an extra boolean which marks that we're suspending, and pass that around, or make it a DSS global variable. I'm not sure why can't you use the sync version just in the suspend callback? To do that the suspend callback should be the one that disables the device and calls pm_runtime_suspend. With DSS that's not the case, it's the panel drivers that are in charge of enabling/disabling DSS (by calling appropriate functions in omapdss). Ah, OK. makes sense. The only thing that the omapdss suspend callback does is to call the normal disable functions on the display drivers. This leads to calls to disable-functions on the dss hwmod drivers, and then pm_runtime_put calls. But at the point the pm_runtime funcs are called, the code has no idea that we're actually doing system suspend. Thus I'd need to pass that information somehow, probably with a global variable. And while that's not difficult to do, it sure feels a bit ugly. I think I'll just change the pm_runtime_put calls to sync versions for now. I imagine the perf impact with the change should be negligible. I'll return to this issue after the devtree adaptation has been made, as it changes the child-parent relations of the dss related devices, and perhaps managing the PM states will also get a bit easier. Sounds reasonable. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: clock: fix mult and div mask for USB_DPLL
Any update on this?
On Wed, Jan 18, 2012 at 3:39 PM, Ameya Palande ameya.pala...@ti.com wrote:
Signed-off-by: Ameya Palande ameya.pala...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..053cc15 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -953,8 +953,8 @@ static struct dpll_data dpll_usb_dd = {
.modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
.autoidle_reg = OMAP4430_CM_AUTOIDLE_DPLL_USB,
.idlest_reg = OMAP4430_CM_IDLEST_DPLL_USB,
- .mult_mask = OMAP4430_DPLL_MULT_MASK,
- .div1_mask = OMAP4430_DPLL_DIV_MASK,
+ .mult_mask = OMAP4430_DPLL_MULT_USB_MASK,
+ .div1_mask = OMAP4430_DPLL_DIV_0_7_MASK,
.enable_mask = OMAP4430_DPLL_EN_MASK,
.autoidle_mask = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask = OMAP4430_ST_DPLL_CLK_MASK,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: Clock: Force a DPLL clkdm/pwrdm ON before a relock
Any update on this?
On Thu, Jan 19, 2012 at 11:22 AM, Ameya Palande ameya.pala...@ti.com wrote:
From: Rajendra Nayak rna...@ti.com
All DPLLs except USB are in ALWON powerdomain. Make sure the
clkdm/pwrdm for USB DPLL (l3init) is turned on before attempting
a DPLL relock. So, mark the database accordingly.
Without this fix, it was seen that DPLL relock fails while testing
relock in a loop of USB DPLL.
CC: Nishanth Menon n...@ti.com
Tested-by: Ameya Palande ameya.pala...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..9519374 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -974,6 +974,7 @@ static struct clk dpll_usb_ck = {
.recalc = omap3_dpll_recalc,
.round_rate = omap2_dpll_round_rate,
.set_rate = omap3_noncore_dpll_set_rate,
+ .clkdm_name = l3_init_clkdm,
};
static struct clk dpll_usb_clkdcoldo_ck = {
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] coupled cpuidle state support
On Fri, Jan 20, 2012 at 12:46 AM, Daniel Lezcano daniel.lezc...@linaro.org wrote: Hi Colin, this patchset could be interesting to resolve in a generic way the cpu dependencies. What is the status of this patchset ? I can't do much with it right now, because I don't have any devices that can do SMP idle with a v3.2 kernel. I've started working on an updated version that avoids the spinlock, but it might be a while before I can test and post it. I'm mostly looking for feedback on the approach taken in this patch, and whether it will be useful for other SoCs besides Tegra and OMAP4. Did you have the opportunity to measure the power consumption with and without this patchset ? Power consumption will be very dependent on the specific SoC in question. The most important factors are the power savings of the independent cpuidle state (normally WFI) vs. the hotplug state (normally 1 cpu in OFF), and the workload being tested. On a very idle system, these patches result in the same total power as hotplugging one cpu and letting the other idle normally. On a 25% busy system, you might see a slight increase in power, as the best independent cpuidle state might be WFI, vs 1 cpu in OFF mode in hotplug. On OMAP4, that difference is small, on the order of 10 mW. Once you hit the threshold where a hotplug governor would have hotplugged in the second cpu (lets say 40%), the savings from these patches are enormous, as you can hit the lowest power state up to 60% of the time, where the hotplug solution would never be going below WFI on both cpus. On OMAP4, that can be well over 100 mW. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/31] ARM: amba: nomadik: get rid of NO_IRQ initializers
- .irq = {IRQ_UART0, NO_IRQ},
+ .irq = {IRQ_UART0},
Acked-by: Alessandro Rubini rub...@unipv.it
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/31] ARM: amba: nomadik: use common amba device initializers
+static AMBA_APB_DEVICE(uart0, uart0, 0, NOMADIK_UART0_BASE,
+ { IRQ_UART0 }, NULL);
Acked-by: Alessandro Rubini rub...@unipv.it
thanks
/alessandro
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 09/31] ARM: amba: samsung: get rid of NO_IRQ initializers
Russell King wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Kukjin Kim kgene@samsung.com
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
---
arch/arm/mach-exynos/dma.c |4 ++--
arch/arm/mach-s5p64x0/dma.c |2 +-
arch/arm/mach-s5pc100/dma.c |4 ++--
arch/arm/mach-s5pv210/dma.c |4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index b10fcd2..8d681bf 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -86,7 +86,7 @@ struct amba_device exynos4_device_pdma0 = {
.end = EXYNOS4_PA_PDMA0 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA0, NO_IRQ},
+ .irq = {IRQ_PDMA0},
.periphid = 0x00041330,
};
@@ -135,7 +135,7 @@ struct amba_device exynos4_device_pdma1 = {
.end = EXYNOS4_PA_PDMA1 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA1, NO_IRQ},
+ .irq = {IRQ_PDMA1},
.periphid = 0x00041330,
};
diff --git a/arch/arm/mach-s5p64x0/dma.c b/arch/arm/mach-s5p64x0/dma.c
index f820c07..99049aa 100644
--- a/arch/arm/mach-s5p64x0/dma.c
+++ b/arch/arm/mach-s5p64x0/dma.c
@@ -119,7 +119,7 @@ struct amba_device s5p64x0_device_pdma = {
.end = S5P64X0_PA_PDMA + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_DMA0, NO_IRQ},
+ .irq = {IRQ_DMA0},
.periphid = 0x00041330,
};
diff --git a/arch/arm/mach-s5pc100/dma.c b/arch/arm/mach-s5pc100/dma.c
index c841f4d3..ac08d7e 100644
--- a/arch/arm/mach-s5pc100/dma.c
+++ b/arch/arm/mach-s5pc100/dma.c
@@ -85,7 +85,7 @@ struct amba_device s5pc100_device_pdma0 = {
.end = S5PC100_PA_PDMA0 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA0, NO_IRQ},
+ .irq = {IRQ_PDMA0},
.periphid = 0x00041330,
};
@@ -139,7 +139,7 @@ struct amba_device s5pc100_device_pdma1 = {
.end = S5PC100_PA_PDMA1 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA1, NO_IRQ},
+ .irq = {IRQ_PDMA1},
.periphid = 0x00041330,
};
diff --git a/arch/arm/mach-s5pv210/dma.c b/arch/arm/mach-s5pv210/dma.c
index a6113e0..8602fa5 100644
--- a/arch/arm/mach-s5pv210/dma.c
+++ b/arch/arm/mach-s5pv210/dma.c
@@ -83,7 +83,7 @@ struct amba_device s5pv210_device_pdma0 = {
.end = S5PV210_PA_PDMA0 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA0, NO_IRQ},
+ .irq = {IRQ_PDMA0},
.periphid = 0x00041330,
};
@@ -139,7 +139,7 @@ struct amba_device s5pv210_device_pdma1 = {
.end = S5PV210_PA_PDMA1 + SZ_4K,
.flags = IORESOURCE_MEM,
},
- .irq = {IRQ_PDMA1, NO_IRQ},
+ .irq = {IRQ_PDMA1},
.periphid = 0x00041330,
};
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 31/31] ARM: amba: samsung: use common amba device initializers
Russell King wrote:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Kukjin Kim kgene@samsung.com
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
---
arch/arm/mach-exynos/dma.c | 38 ++
arch/arm/mach-s5p64x0/dma.c | 22 +-
arch/arm/mach-s5pc100/dma.c | 38 ++
arch/arm/mach-s5pv210/dma.c | 38 ++
4 files changed, 23 insertions(+), 113 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index 8d681bf..91370de 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -74,21 +74,8 @@ struct dma_pl330_platdata exynos4_pdma0_pdata = {
.peri_id = pdma0_peri,
};
-struct amba_device exynos4_device_pdma0 = {
- .dev = {
- .init_name = dma-pl330.0,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = exynos4_pdma0_pdata,
- },
- .res = {
- .start = EXYNOS4_PA_PDMA0,
- .end = EXYNOS4_PA_PDMA0 + SZ_4K,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_PDMA0},
- .periphid = 0x00041330,
-};
+AMBA_AHB_DEVICE(exynos4_pdma0, dma-pl330.0, 0x00041330, EXYNOS4_PA_PDMA0,
+ {IRQ_PDMA0}, exynos4_pdma0_pdata);
u8 pdma1_peri[] = {
DMACH_PCM0_RX,
@@ -123,21 +110,8 @@ struct dma_pl330_platdata exynos4_pdma1_pdata = {
.peri_id = pdma1_peri,
};
-struct amba_device exynos4_device_pdma1 = {
- .dev = {
- .init_name = dma-pl330.1,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = exynos4_pdma1_pdata,
- },
- .res = {
- .start = EXYNOS4_PA_PDMA1,
- .end = EXYNOS4_PA_PDMA1 + SZ_4K,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_PDMA1},
- .periphid = 0x00041330,
-};
+AMBA_AHB_DEVICE(exynos4_pdma1, dma-pl330.1, 0x00041330, EXYNOS4_PA_PDMA1,
+ {IRQ_PDMA1}, exynos4_pdma1_pdata);
static int __init exynos4_dma_init(void)
{
@@ -146,11 +120,11 @@ static int __init exynos4_dma_init(void)
dma_cap_set(DMA_SLAVE, exynos4_pdma0_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, exynos4_pdma0_pdata.cap_mask);
- amba_device_register(exynos4_device_pdma0, iomem_resource);
+ amba_device_register(exynos4_pdma0_device, iomem_resource);
dma_cap_set(DMA_SLAVE, exynos4_pdma1_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, exynos4_pdma1_pdata.cap_mask);
- amba_device_register(exynos4_device_pdma1, iomem_resource);
+ amba_device_register(exynos4_pdma1_device, iomem_resource);
return 0;
}
diff --git a/arch/arm/mach-s5p64x0/dma.c b/arch/arm/mach-s5p64x0/dma.c
index 99049aa..f7f68ad 100644
--- a/arch/arm/mach-s5p64x0/dma.c
+++ b/arch/arm/mach-s5p64x0/dma.c
@@ -108,34 +108,22 @@ struct dma_pl330_platdata s5p6450_pdma_pdata = {
.peri_id = s5p6450_pdma_peri,
};
-struct amba_device s5p64x0_device_pdma = {
- .dev = {
- .init_name = dma-pl330,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .res = {
- .start = S5P64X0_PA_PDMA,
- .end = S5P64X0_PA_PDMA + SZ_4K,
- .flags = IORESOURCE_MEM,
- },
- .irq = {IRQ_DMA0},
- .periphid = 0x00041330,
-};
+AMBA_AHB_DEVICE(s5p64x0_pdma, dma-pl330, 0x00041330, S5P64X0_PA_PDMA,
+ {IRQ_DMA0}, NULL);
static int __init s5p64x0_dma_init(void)
{
if (soc_is_s5p6450()) {
dma_cap_set(DMA_SLAVE, s5p6450_pdma_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, s5p6450_pdma_pdata.cap_mask);
- s5p64x0_device_pdma.dev.platform_data = s5p6450_pdma_pdata;
+ s5p64x0_pdma_device.dev.platform_data = s5p6450_pdma_pdata;
} else {
dma_cap_set(DMA_SLAVE, s5p6440_pdma_pdata.cap_mask);
dma_cap_set(DMA_CYCLIC, s5p6440_pdma_pdata.cap_mask);
- s5p64x0_device_pdma.dev.platform_data = s5p6440_pdma_pdata;
+ s5p64x0_pdma_device.dev.platform_data = s5p6440_pdma_pdata;
}
- amba_device_register(s5p64x0_device_pdma, iomem_resource);
+ amba_device_register(s5p64x0_pdma_device, iomem_resource);
return 0;
}
diff --git a/arch/arm/mach-s5pc100/dma.c b/arch/arm/mach-s5pc100/dma.c
index ac08d7e..96b1ab3 100644
--- a/arch/arm/mach-s5pc100/dma.c
+++ b/arch/arm/mach-s5pc100/dma.c
@@ -73,21 +73,8 @@ struct dma_pl330_platdata s5pc100_pdma0_pdata = {
.peri_id = pdma0_peri,
};
-struct amba_device s5pc100_device_pdma0 = {
- .dev = {
- .init_name = dma-pl330.0,
- .dma_mask = dma_dmamask,
- .coherent_dma_mask
RE: [PATCH 00/31] Clean up amba/primecell bus support
Russell King - ARM Linux wrote: This patch set cleans up the AMBA/Primecell bus support. Contained within this set are: 1. Patches 1-5 - Allocation APIs It seems several places in the kernel want to allocate and register amba_device structures. Let's make this official, and common code. So we introduce amba_device_alloc(), amba_device_add(), and amba_device_put() APIs, which provide the necessary support safely for this. Convert the DT, ux500, Integrator/AP and mxs code to use these APIs rather than their private version. 2. Patches 6-17 - NO_IRQ cleanup Making IRQ number 0 mean 'no irq' for the AMBA drivers and bus layer. We get rid of NO_IRQ initializers in this across various platforms, and make the bus layer warn if '-1' is passed in a device as an IRQ. This prevents new occurances of NO_IRQ initializers for this bus type going by unspotted. 3. Patches 18-31 - static initializers Provide a standardized set of initializers for statically declared AMBA devices. We provide two - one for the simpler APB devices, and one for AHB devices. The major difference between these two is the setting of the DMA mask - APB peripherals do not have DMA capability themselves. While updating (3), I came across new additions in Spear3xx and the Samsung directories which added AMBA devices, which are declared globally. The Spear3xx devices are used in other files, so that's fine. Samsung devices don't seem to be - and that needs fixing (did someone not run checkpatch or sparse on these changes?) Please send fixes. Yeah, you're right. They in Samsung directories are not used anywhere else. So statically declaration can be used. As a note, I always run checkpatch but sparse before applying but unfortunately, checkpatch didn't complain about that. Let me check where fixes are needed in Samsung directories then send it. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Acks for these patches are welcome. arch/arm/mach-bcmring/core.c | 23 +- arch/arm/mach-ep93xx/core.c| 46 ++- arch/arm/mach-exynos/dma.c | 38 ++--- arch/arm/mach-integrator/core.c| 70 +++- arch/arm/mach-integrator/impd1.c |9 +-- arch/arm/mach-integrator/integrator_cp.c | 49 ++- arch/arm/mach-lpc32xx/phy3250.c| 32 +-- arch/arm/mach-mxs/devices.c|8 +- arch/arm/mach-mxs/devices/amba-duart.c |2 +- arch/arm/mach-netx/fb.c| 13 +--- arch/arm/mach-nomadik/board-nhk8815.c | 17 +--- arch/arm/mach-nomadik/cpu-8815.c |9 +-- arch/arm/mach-omap2/emu.c | 26 +-- arch/arm/mach-realview/core.h | 20 + arch/arm/mach-realview/realview_eb.c | 78 +- arch/arm/mach-realview/realview_pb1176.c | 78 +- arch/arm/mach-realview/realview_pb11mp.c | 78 +- arch/arm/mach-realview/realview_pba8.c | 78 +- arch/arm/mach-realview/realview_pbx.c | 78 +- arch/arm/mach-s5p64x0/dma.c| 22 + arch/arm/mach-s5pc100/dma.c| 38 ++--- arch/arm/mach-s5pv210/dma.c| 38 ++--- arch/arm/mach-spear3xx/spear300.c | 14 +--- arch/arm/mach-spear3xx/spear3xx.c | 27 +- arch/arm/mach-spear6xx/spear6xx.c | 10 +- arch/arm/mach-u300/core.c | 85 arch/arm/mach-ux500/devices-common.c | 13 +-- arch/arm/mach-versatile/core.c | 70 arch/arm/mach-versatile/core.h | 20 + arch/arm/mach-versatile/versatile_pb.c | 18 ++-- arch/arm/mach-vexpress/core.h | 17 arch/arm/mach-vexpress/ct-ca9x4.c |8 +- arch/arm/mach-vexpress/include/mach/ct-ca9x4.h |2 +- arch/arm/mach-vexpress/v2m.c | 20 ++-- drivers/amba/bus.c | 105 ++-- drivers/mmc/host/mmci.c|2 +- drivers/of/platform.c |6 +- include/linux/amba/bus.h | 36 38 files changed, 488 insertions(+), 815 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian eran...@googlemail.com wrote: Started afresh from: 90a4c0f uml: fix compile for x86-64 And added 3, 4, 5, 6: 603c316 arm: omap4: pmu: support runtime pm 4899fbd arm: omap4: support pmu d737bb1 arm: omap4: create pmu device via hwmod 4e0259e arm: omap4: hwmod: introduce emu hwmod Still no interrupts firing. I am using your .config file. My HW: CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part : 0xc09 CPU revision : 2 Hardware : OMAP4 Panda board Revision : 0020 There must be something I am missing here. Have you applied the patch in link[1]? thanks, -- Ming Lei [1], http://marc.info/?l=linux-arm-kernelm=132697975416659w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 PATCH 1/3] dt: device tree bindings for DDR memories
On Thu, Jan 19, 2012 at 12:56 PM, Aneesh V ane...@ti.com wrote: Hi Olof, On Friday 20 January 2012 01:01 AM, Olof Johansson wrote: Hi, Sorry for the delay in responding, I know you pinged me about it yesterday. On Thu, Jan 19, 2012 at 6:31 AM, Aneesh Vane...@ti.com wrote: device tree bindings for LPDDR2 SDRAM memories compliant to JESD209-2 standard. The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings' for specifying the AC timing parameters of the memory device at different speed-bins. As I just commented on the thread with Mike, I think we would be better off sticking to embedding a standard JEDEC SPD structure in the device tree. It's not large (128-256 bytes depending on memory type), and it's clearly defined and used all over the industry. It also has the benefit of reusing parsing code if you ever end up with a system that uses DIMMs for memory, thus needing to parse the SPD on said modules. I did mention in the previous thread why SPD doesn't work for us ([1] and [2]). Let me repeat the key points here. Ah, sorry. Missed it in the chain of replies. 1. I couldn't find an SPD addendum for LPDDR2 from the JEDEC website. 2. This seems to indicate that SPD is not used for LPDDR2 devices. Bummer. I'm guessing most applications where LPDDR* is used won't be suitable for modular memory, so there's not the same need for SPD. 3. I tried to see if I can fit the DDR3 or DDR2 SPD for our needs. But some of the AC timing parameters needed by our controller are not available in those layouts. Are those properties of the memory, or a combination of memory and board properties? I think it still makes sense for the memories that do have it to use the SPD format and extend with additional properties, at least if it's only a few additional properties needed. I don't see any option other than defining a new binding for LPDDR2. Yeah, agreed. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode
Ensure FIFO levels are set correctly in non-DMA mode (the default).
This patch will cause a receive FIFO threshold interrupt to be raised when
there is at least one byte in the RX FIFO. It will also cause a transmit
FIFO threshold interrupt when there is only one byte remaining in the TX
FIFO.
These changes fix the receive interrupt problem and part of the
transmit interrupt problem. A separate set of issues must be worked
around for the transmit path to have a basic level of functionality; a
subsequent patch will address these.
DMA operation is unaffected by this patch.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Govindraj Raja govindra...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
drivers/tty/serial/omap-serial.c | 35 +++
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d192dcb..9de7d71 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -46,6 +46,18 @@
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+/* SCR register bitmasks */
+#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7)
+#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6)
+
+/* FCR register bitmasks */
+#define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
+#define OMAP_UART_FCR_RX_FIFO_TRIG_MASK(0x3 6)
+#define OMAP_UART_FCR_TX_FIFO_TRIG_SHIFT 4
+
+/* TLR register bitmasks */
+#define OMAP_UART_TLR_TX_FIFO_TRIG_DMA_SHIFT 0
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -694,6 +706,7 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
unsigned char efr = 0;
unsigned long flags = 0;
unsigned int baud, quot;
+ u32 tlr;
switch (termios-c_cflag CSIZE) {
case CS5:
@@ -811,14 +824,28 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
up-mcr = serial_in(up, UART_MCR);
serial_out(up, UART_MCR, up-mcr | UART_MCR_TCRTLR);
/* FIFO ENABLE, DMA MODE */
- serial_out(up, UART_FCR, up-fcr);
- serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+
+ up-scr |= OMAP_UART_SCR_TX_TRIG_GRANU1_MASK;
+ up-scr |= OMAP_UART_SCR_RX_TRIG_GRANU1_MASK;
if (up-use_dma) {
- serial_out(up, UART_TI752_TLR, 0);
- up-scr |= (UART_FCR_TRIGGER_4 | UART_FCR_TRIGGER_8);
+ tlr = 0;
+ } else {
+ up-scr = ~OMAP_UART_SCR_TX_EMPTY;
+
+ /* Set receive FIFO threshold to 1 */
+ up-fcr = ~OMAP_UART_FCR_RX_FIFO_TRIG_MASK;
+ up-fcr |= (0x1 OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT);
+
+ /* Set TX FIFO threshold to 63 (actually 1) */
+ up-fcr |= (0x3 OMAP_UART_FCR_TX_FIFO_TRIG_SHIFT);
+ tlr = (0xf OMAP_UART_TLR_TX_FIFO_TRIG_DMA_SHIFT);
}
+ serial_out(up, UART_TI752_TLR, tlr);
+ serial_out(up, UART_FCR, up-fcr);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+
serial_out(up, UART_OMAP_SCR, up-scr);
serial_out(up, UART_EFR, up-efr);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] tty: serial: OMAP: work around broken driver, IP block
[ This series is targeted for merging during v3.3-rc ] On v3.3-rc1, the OMAP serial console doesn't behave properly when power management is enabled (the default with omap2plus_defconfig). This seems to be due to a combination of a silicon bug in the UART IP block and broken FIFO settings in the OMAP serial driver. This patch series attempts to work around these problems. The workarounds are not perfect; see the patch descriptions for more details. Tested on OMAP3530 BeagleBoard. This series will need to be tested on OMAP2 and OMAP4 before it is ready to merge. - Paul --- Paul Walmsley (2): tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip arch/arm/plat-omap/include/plat/omap-serial.h |1 drivers/tty/serial/omap-serial.c | 86 - 2 files changed, 82 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip
It seems that when the transmit FIFO threshold is reached on OMAP
UARTs, it does not result in a PRCM wakeup. This appears to be a
silicon bug. This means that if the MPU powerdomain is in a low-power
state, the MPU will not be awakened to refill the FIFO until the next
interrupt from another device.
The best solution, at least for the short term, would be for the OMAP
serial driver to call a OMAP subarchitecture function to prevent the
MPU powerdomain from entering a low power state while the FIFO has
data to transmit. However, we no longer have a clean way to do this,
since patches that add platform_data function pointers have been
deprecated by the OMAP maintainer. So we attempt to work around this
as well. The workarounds depend on the setting of CONFIG_CPU_IDLE.
When CONFIG_CPU_IDLE=n, the driver will now only transmit one byte at
a time. This causes the transmit FIFO threshold interrupt to stay
active until there is no more data to be sent. Thus, the MPU
powerdomain stays on during transmits. Aside from that energy
consumption penalty, each transmitted byte results in a huge number of
UART interrupts -- about five per byte. This wastes CPU time and is
quite inefficient, but is probably the most expedient workaround in
this case.
When CONFIG_CPU_IDLE=y, there is a slightly more direct workaround:
the PM QoS constraint can be abused to keep the MPU powerdomain on.
This results in a normal number of interrupts, but, similar to the
above workaround, wastes power by preventing the MPU from entering
WFI.
Future patches are planned for the 3.4 merge window to implement more
efficient, but also more disruptive, workarounds to these problems.
DMA operation is unaffected by this patch.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Govindraj Raja govindra...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |1
drivers/tty/serial/omap-serial.c | 51 +
2 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..12a64eb 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -131,6 +131,7 @@ struct uart_omap_port {
u32 context_loss_cnt;
u32 errata;
u8 wakeups_enabled;
+ u8 max_tx_count;
struct pm_qos_request pm_qos_request;
u32 latency;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 9de7d71..621fde5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -88,6 +88,49 @@ static inline void serial_omap_clear_fifos(struct
uart_omap_port *up)
serial_out(up, UART_FCR, 0);
}
+/**
+ * serial_omap_block_cpu_low_power_state - prevent MPU pwrdm from leaving ON
+ * @up: struct uart_omap_port *
+ *
+ * Prevent the MPU powerdomain from entering a power state lower than
+ * ON. (It should be sufficient to prevent it from entering INACTIVE,
+ * but there is presently no easy way to do this.) This works around
+ * a suspected silicon bug in the OMAP UART IP blocks. The UARTs should
+ * wake the PRCM when the transmit FIFO threshold interrupt is raised, but
+ * they do not. See also serial_omap_allow_cpu_low_power_state(). No
+ * return value.
+ */
+static void serial_omap_block_cpu_low_power_state(struct uart_omap_port *up)
+{
+#ifdef CONFIG_CPU_IDLE
+ up-latency = 1;
+ schedule_work(up-qos_work);
+#else
+ up-max_tx_count = 1;
+#endif
+}
+
+/**
+ * serial_omap_allow_cpu_low_power_state - remove power state restriction on
MPU
+ * @up: struct uart_omap_port *
+ *
+ * Cancel the effects of serial_omap_block_cpu_low_power_state().
+ * This should allow the MPU powerdomain to enter a power state lower
+ * than ON, assuming the rest of the kernel is not restricting it.
+ * This works around a suspected silicon bug in the OMAP UART IP
+ * blocks. The UARTs should wake the PRCM when the transmit FIFO
+ * threshold interrupt is raised, but they do not. No return value.
+ */
+static void serial_omap_allow_cpu_low_power_state(struct uart_omap_port *up)
+{
+#ifdef CONFIG_CPU_IDLE
+ up-latency = up-calc_latency;
+ schedule_work(up-qos_work);
+#else
+ up-max_tx_count = up-port.fifosize / 4;
+#endif
+}
+
/*
* serial_omap_get_divisor - calculate divisor value
* @port: uart port info
@@ -163,6 +206,9 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
+ if (!up-use_dma)
+ serial_omap_allow_cpu_low_power_state(up);
+
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
}
@@ -264,7 +310,7 @@ static void transmit_chars(struct
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 20 Jan 2012, Tomi Valkeinen wrote: I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. Have noticed that serial is pretty broken also. Maybe try this series: http://marc.info/?l=linux-omapm=132713119729167w=2 http://marc.info/?l=linux-omapm=132713119229165w=2 http://marc.info/?l=linux-omapm=132713119829168w=2 which is also available via git from git://git.pwsan.com/linux-2.6 in the branch omap_serial_fixes_3.3rc - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 20 Jan 2012, Tomi Valkeinen wrote: On Fri, 2012-01-20 at 16:19 +0530, Govindraj wrote: On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably related to PM. First, when I boot up, the console (via USB serial) is very laggy, it often takes many seconds until the key pressed appears so it's more or less unusable. can you try enabling CONFIG_CPU_IDLE ? Enabling CPU_IDLE does remove the problems. I don't know what it's supposed to do, but it seems to keep the MPU and DSS in ON state all the time, so the problem disappears. Enabling CONFIG_CPU_IDLE doesn't fix it for me. Maybe that's because I'm just using omap2plus_defconfig. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 20 Jan 2012, Govindraj wrote: 3.3-rc1 has uart runtime patches merged we have removed uart dependency for system to enter low powers states and used pm_qos calls, but pm_qos api's seem do get activated only by enabling config_cpu_idle. Question to kevin/Paul, Shouldn't system be doing wfi if cpu_idle is not enabled ? since we are mapping omap3_pm_idle to pm_idle thread system enters low power states even if config_cpu_idle is not enabled. Is this expected behavior? Yes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM(?) problems on v3.3-rc1 on OMAP3
On Fri, 20 Jan 2012, Tomi Valkeinen wrote: Third, when I load the DSS modules, I see only ON state increasing for dss_pwrdm, as it should be. However, I'm getting constant stream of sync losts from DSS, and the display doesn't basically work at all. I can see MPU pwrdm going into RET a lot, and if I do while true; do echo foo; done, which I presume basically prevents RET for MPU, the display becomes stable. If this particular problem persists after you apply the patch set that I sent earlier, it suggests that something in the DSS is sensitive to the amount of time it takes the MPU to wake up and service an interrupt when the MPU powerdomain is in a low-power state. Total guess, but perhaps omap_dispc_irq_handler() is getting called after each frame and needs to run within a certain bounded time when that happens? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
