Re: How to (get a struct device* to) map a DMA buffer for McBSP?
I had exactly the same problem. It looks like the struct omap_mcbsp array was
intended to be accessible
From include/plat/mcbsp.h
extern struct omap_mcbsp **mcbsp_ptr;
I couldn't get access to mcbsp_ptr in an out of tree module. So I added this
arch/arm/plat-omap/include/plat/mcbsp.h
+struct omap_mcbsp* omap_mcbsp_get_mcbsp_ptr(u8 id);
arch/arm/plat-omap/mcbsp.c
+struct omap_mcbsp* omap_mcbsp_get_mcbsp_ptr(u8 id)
+{
+ if (!omap_mcbsp_check_valid_id(id))
+ return NULL;
+
+ return id_to_mcbsp_ptr(id);
+}
+EXPORT_SYMBOL(omap_mcbsp_get_mcbsp_ptr);
+
This was to could get access to .phys_base and .dma_rx_sync for my own DMA ops.
Is there a better way?
--
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: Inventra Highspeed Dual Role Controller on TI OMAP 3503
Hi, On Fri, 26 Nov 2010 21:36:56 +0400, Elvis Dowson elvis.dow...@mac.com wrote: Hi, Is the Inventra Highspeed Dual Role Controller silicon IP available on the TI OMAP 3503? yes it is there. The kernel config help documentation mentions only TI OMAP 353x and I'm not sure if that implies that it isn't present in the TI OMAP 3503 processor. that's no official documentation. It's better to check device's datasheet when you have such questions. Besides, imagine the pain it would be to patch that Kconfig entry everytime we have a new release of an OMAP processor. Maybe it would be better to say something like: available on many OMAP processors instead of mentioning each and every one of them. -- balbi -- 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/PATCH v6 05/12] media: Reference count and power handling
Hi Mark, On Thursday 25 November 2010 22:47:09 Mark Brown wrote: On Thu, Nov 25, 2010 at 07:49:05PM +0200, Sakari Ailus wrote: Currently when two media entities are connected they will be powered up for the duration of the link setup, just in case the drivers would need to access hardware for some reason. I don't think we have a need for that at the moment, it's so just because it seemed to be the right thing to do. This is *really* bad for audio, powering things on and off needlessly can cause audible effects for users. If the individual drivers need to do something they can go and implement that but powering things up by default seems like it'll at best waste power most of the time. The OMAP3 ISP driver required entities to be powered on when link attributes were modified, but that's not true anymore. We could remove this feature, or make it optional. Essentially the idea is that the drivers do not need to be involved with the power state handling and the device would be powered always when they are run, but not be powered when it's not necessary. This is what DAPM does in ASoC at the minute. What it does is that every time there is a change in the device configuration which might have affected the power state it walks the graph of power nodes in the system. If there has been a change in the state the core will generate a power transition sequence and apply it. The devices have no knowledge of this (though they can insert manual sequences for nodes if they need to), for the most part they just describe the graph and the register bits that control the power for the nodes and the routing. Subdev is a V4L2 specific concept and I don't know if ALSA would benefit from something similar. If you want to be able to access the individual enties from user space, then similar arrangement might be useful. ALSA already has this feature (at least in the embedded case, HDA has some of these features too). I don't see a problem in applying restrictions on power on / off sequence. They would probably be useful also on the V4L2 side in the future. Could the restrictions be described as dependencies only, i.e. entity 1 power-up requires entity 2 to be powered first, also meaning that entity 2 could be powered down only after entity 1 has been powered down? No. Audio power sequencing tends to work better if sorted by the type of object rather than the route (though using the route as a lower order sort key can be useful). It's also useful to coalesce the I/O on the hardware for performance (both speed and user experience). The way we're currently doing it the sequencing is actually separated from the graph walk - the result of the graph walk is a set of things that need doing which is then implemented in a separate step. I think this would be the easiest way to integrate with what you're doing at the minute, keep the same split and then ASoC can do the postprocessing of the results of the graph walk in the same way as it does currently. Throwing an idea here, what about making power management modular ? The MC core would then call back to drivers to handle use count changes. The media_entity_use_change() function would be exported (and renamed), so that drivers could use it if they want graph-based power management. ALSA would have its own use count handler. -- Regards, Laurent Pinchart -- 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/PATCH v6 03/12] media: Entities, pads and links
Hi Mark, On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? -- Regards, Laurent Pinchart -- 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/PATCH v6 03/12] media: Entities, pads and links
On Sunday, November 28, 2010 13:34:45 Laurent Pinchart wrote: Hi Mark, On Friday 26 November 2010 15:14:42 Mark Brown wrote: On Fri, Nov 26, 2010 at 03:13:36PM +0100, Laurent Pinchart wrote: On Thursday 25 November 2010 16:49:52 Mark Brown wrote: On Thu, Nov 25, 2010 at 04:40:41PM +0100, Laurent Pinchart wrote: It's supposed to reflect whether the link can carry data. Think of the active flag as a valve on a pipe. If the valve is open, the link is active. If the valve is closed, the link is inactive. This is unrelated to whether water actually flows through the pipe. This seems a confusing name, then - I'd expect an active link to be one which is actually carrying data rather than one which is available to carry data. How a more neutrally worded name such as connected (which is what ASoC uses currently)? In our current vocabulary connected refers to entities between which a link exist, regardless of the link state (valve opened or valve closed). I'm not totally happy with active either, but if we replace it with connected we need another word to replace current uses of connected. Linked? That's a good option. Hans, do you want to comment on this ? Fine by me! It's better than 'active'. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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/PATCH v6 05/12] media: Reference count and power handling
On 28 Nov 2010, at 12:33, Laurent Pinchart wrote: Throwing an idea here, what about making power management modular ? The MC core would then call back to drivers to handle use count changes. The media_entity_use_change() function would be exported (and renamed), so that drivers could use it if they want graph-based power management. ALSA would have its own use count handler. We need more than just the count handler - we need a complete list of everything that has been changed in the whole system. The graph walk itself is fine but we need to be able to do postprocessing of the delta that is generated. Like I said pre- and post- callbacks may well cover it. Note that this is specifically for ASoC, not ALSA in general.-- 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: [Query]McSPI testing help on N800
On Fri, 26 Nov 2010, Datta, Shubhrajyoti wrote: We were wondering how to test McSPI on N800. Is there any peripheral connected to McSPI? These devices are configured in the board file for the device, which is arch/arm/mach-omap2/board-n8x0.c - 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: [PATCH 1/6] OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap
Hello Rajendra,
some comments:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
The platform-independent code would reside in plat-omap/powerdomain.c
and the platform-specific code will resides in
mach-omap2/powerdomain-.c files.
Since we're not implementing powerdomain support for OMAP1 right now, is
there any reason why we can't just leave the powerdomain-common stuff in
the mach-omap2/ directory for now?
Some of the hacks to include header files are done to make sure the
patch compiles and works fine. These hacks will be removed in the
subsequent patches.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/plat-omap/Makefile |6 +++---
arch/arm/{mach-omap2 = plat-omap}/powerdomain.c | 14 +++---
3 files changed, 11 insertions(+), 11 deletions(-)
rename arch/arm/{mach-omap2 = plat-omap}/powerdomain.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..4bfadc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -9,7 +9,7 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o
timer-gp.o pm.o \
omap-2-3-common = irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
omap_hwmod_common_data.o
-prcm-common = prcm.o powerdomain.o
+prcm-common = prcm.o
clock-common = clock.o clock_common_data.o \
clockdomain.o clkt_dpll.o \
clkt_clksel.o
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..424a9ae 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -13,9 +13,9 @@ obj- :=
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# omap_device support (OMAP2+ only at the moment)
-obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP2) += omap_device.o powerdomain.o
+obj-$(CONFIG_ARCH_OMAP3) += omap_device.o powerdomain.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_device.o powerdomain.o
The powerdomain code isn't directly related to the omap_device code, so
please create a new section in the mach-omap2/Makefile for this stuff.
Perhaps something like:
# OMAP PRCM powerdomain support
obj-$(CONFIG_ARCH_OMAP2) += powerdomain.o
obj-$(CONFIG_ARCH_OMAP3) += powerdomain.o
obj-$(CONFIG_ARCH_OMAP4) += powerdomain.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/plat-omap/powerdomain.c
similarity index 99%
rename from arch/arm/mach-omap2/powerdomain.c
rename to arch/arm/plat-omap/powerdomain.c
(see the first comment)
index 6527ec3..9204799 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -26,19 +26,19 @@
#include asm/atomic.h
-#include cm.h
-#include cm-regbits-34xx.h
-#include cm-regbits-44xx.h
-#include prm.h
-#include prm-regbits-34xx.h
-#include prm-regbits-44xx.h
+#include ../mach-omap2/cm.h
+#include ../mach-omap2/cm-regbits-34xx.h
+#include ../mach-omap2/cm-regbits-44xx.h
+#include ../mach-omap2/prm.h
+#include ../mach-omap2/prm-regbits-34xx.h
+#include ../mach-omap2/prm-regbits-44xx.h
#include plat/cpu.h
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/prcm.h
-#include pm.h
+#include ../mach-omap2/pm.h
enum {
PWRDM_STATE_NOW = 0,
--
1.7.0.4
- 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: [PATCH 2/6] OMAP: powerdomain: Infrastructure to put arch specific code
One minor comment here:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/include/plat/powerdomain.h | 22 +-
arch/arm/plat-omap/powerdomain.c | 10 --
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..76c531a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -316,7 +316,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
u8 skip_setup_idle = 0;
- pwrdm_init(powerdomains_omap);
+ pwrdm_init(powerdomains_omap, NULL);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
omap2420_hwmod_init();
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 9ca420d..35e1ef7 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -117,8 +117,28 @@ struct powerdomain {
#endif
};
+struct pwrdm_functions {
+ int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_logic_retst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_set_mem_onst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_set_mem_retst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_read_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_logic_retst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_mem_pwrst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_read_prev_mem_pwrst)(struct powerdomain *pwrdm, u8
bank);
+ int (*pwrdm_read_mem_retst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_clear_all_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_enable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
+ int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
+};
-void pwrdm_init(struct powerdomain **pwrdm_list);
+void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_functions
*custom_funcs);
struct powerdomain *pwrdm_lookup(const char *name);
diff --git a/arch/arm/plat-omap/powerdomain.c
b/arch/arm/plat-omap/powerdomain.c
index 9204799..9e2d712 100644
--- a/arch/arm/plat-omap/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -80,6 +80,8 @@ static u16 pwrstst_reg_offs;
/* pwrdm_list contains all registered struct powerdomains */
static LIST_HEAD(pwrdm_list);
+static struct pwrdm_functions *arch_pwrdm;
+
/* Private functions */
static struct powerdomain *_pwrdm_lookup(const char *name)
@@ -218,7 +220,7 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
* registered. No return value. XXX pwrdm_list is not really a
* list; it is an array. Rename appropriately.
*/
-void pwrdm_init(struct powerdomain **pwrdm_list)
+void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_functions
*custom_funcs)
{
struct powerdomain **p = NULL;
@@ -234,6 +236,11 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
return;
}
+ if (!custom_funcs)
+ WARN(1, No custom pwrdm functions registered\n);
It's probably best to prefix this message with powerdomain:
+ else
+ arch_pwrdm = custom_funcs;
+
if (pwrdm_list) {
for (p = pwrdm_list; *p; p++)
_pwrdm_register(*p);
@@ -1074,4 +1081,3 @@ int pwrdm_post_transition(void)
pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
-
--
1.7.0.4
- 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: [PATCH 3/6] OMAP: powerdomain: Arch specific funcs for state control
Some comments below:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_next_pwrst
.pwrdm_read_next_pwrst
.pwrdm_read_pwrst
.pwrdm_read_prev_pwrst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |5 +++
arch/arm/mach-omap2/io.c |5 ++-
arch/arm/mach-omap2/powerdomains.h |8 +
arch/arm/mach-omap2/powerdomains2xxx.c | 53
arch/arm/mach-omap2/powerdomains44xx.c | 53
arch/arm/plat-omap/powerdomain.c | 33 ++--
6 files changed, 146 insertions(+), 11 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomains2xxx.c
create mode 100644 arch/arm/mach-omap2/powerdomains44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4bfadc5..5f843fc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -94,6 +94,11 @@ obj-$(CONFIG_ARCH_OMAP2430)+=
omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
+#powerdomain framework
+obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx.o
+obj-$(CONFIG_ARCH_OMAP3) += powerdomains2xxx.o
We're going to need a separate file for OMAP3, because there are some
PRCM powerdomain features that are not present on OMAP2.
Please move the functions that are common between OMAP2xxx and OMAP3 into
a separate file -- maybe something like powerdomain_2xxx_3xxx.o. Then
powerdomain2xxx.c and powerdomain3xxx.c can just put pointers into
pwrdm_functions in that file for the common stuff. Unfortunately, we
won't be able to keep those common functions static at that point.
+obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx.o
+
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU) += emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 76c531a..c68e989 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -316,7 +316,10 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
u8 skip_setup_idle = 0;
- pwrdm_init(powerdomains_omap, NULL);
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ pwrdm_init(powerdomains_omap, omap2_pwrdm_functions);
+ else if (cpu_is_omap44xx())
+ pwrdm_init(powerdomains_omap, omap4_pwrdm_functions);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
omap2420_hwmod_init();
diff --git a/arch/arm/mach-omap2/powerdomains.h
b/arch/arm/mach-omap2/powerdomains.h
index 105cbca..b25b989 100644
--- a/arch/arm/mach-omap2/powerdomains.h
+++ b/arch/arm/mach-omap2/powerdomains.h
@@ -88,8 +88,16 @@ static struct powerdomain wkup_omap2_pwrdm = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
};
+extern struct pwrdm_functions omap2_pwrdm_functions;
+#else
+static struct pwrdm_functions omap2_pwrdm_functions;
#endif
+#ifdef CONFIG_ARCH_OMAP4
+extern struct pwrdm_functions omap4_pwrdm_functions;
+#else
+static struct pwrdm_functions omap4_pwrdm_functions;
+#endif
/* As powerdomains are added or removed above, this list must also be
changed */
static struct powerdomain *powerdomains_omap[] __initdata = {
diff --git a/arch/arm/mach-omap2/powerdomains2xxx.c
b/arch/arm/mach-omap2/powerdomains2xxx.c
new file mode 100644
index 000..dfeb8af
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains2xxx.c
@@ -0,0 +1,53 @@
+/*
+ * OMAP2 and OMAP3 powerdomain control
+ *
+ * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2007-2009 Nokia Corporation
+ *
+ * Derived from mach-omap2/powerdomain.c written by Paul Walmsley
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/io.h
+#include linux/errno.h
+#include linux/delay.h
+#include plat/powerdomain.h
+#include plat/prcm.h
+#include powerdomains.h
+
+static int omap2_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
+ (pwrst OMAP_POWERSTATE_SHIFT),
+ pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL);
+ return 0;
+}
+
+static int omap2_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ OMAP2_PM_PWSTCTRL,
Re: [PATCH 4/6] OMAP: powerdomain: Arch specific funcs for logic control
Some comments:
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_logic_retst
.pwrdm_read_logic_pwrst
.pwrdm_read_prev_logic_pwrst
.pwrdm_read_logic_retst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains2xxx.c | 34 +
arch/arm/mach-omap2/powerdomains44xx.c | 26
arch/arm/plat-omap/powerdomain.c | 51
++--
3 files changed, 82 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains2xxx.c
b/arch/arm/mach-omap2/powerdomains2xxx.c
index dfeb8af..779529d 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx.c
@@ -45,9 +45,43 @@ static int omap2_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
OMAP3430_LASTPOWERSTATEENTERED_MASK);
}
+static int omap2_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ u32 v;
+
+ v = pwrst __ffs(OMAP3430_LOGICL1CACHERETSTATE_MASK);
+ prm_rmw_mod_reg_bits(OMAP3430_LOGICL1CACHERETSTATE_MASK, v,
+ pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL);
+
+ return 0;
+}
+
+static int omap2_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP2_PM_PWSTST,
+ OMAP3430_LOGICSTATEST_MASK);
+}
Not present on OMAP2xxx, so, does not belong here.
+
+
+static int omap2_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP3430_PM_PREPWSTST,
+ OMAP3430_LASTLOGICSTATEENTERED_MASK);
+}
Not present on OMAP2xxx, so, does not belong here.
+
+static int omap2_pwrdm_read_logic_retst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL,
+ OMAP3430_LOGICSTATEST_MASK);
+}
Not present on OMAP2xxx, so, does not belong here.
+
struct pwrdm_functions omap2_pwrdm_functions = {
.pwrdm_set_next_pwrst = omap2_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = omap2_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = omap2_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap2_pwrdm_read_prev_pwrst,
+ .pwrdm_set_logic_retst = omap2_pwrdm_set_logic_retst,
+ .pwrdm_read_logic_pwrst = omap2_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap2_pwrdm_read_prev_logic_pwrst,
+ .pwrdm_read_logic_retst = omap2_pwrdm_read_logic_retst,
};
diff --git a/arch/arm/mach-omap2/powerdomains44xx.c
b/arch/arm/mach-omap2/powerdomains44xx.c
index b3aaf9b..016a425 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.c
+++ b/arch/arm/mach-omap2/powerdomains44xx.c
@@ -45,9 +45,35 @@ static int omap4_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
OMAP4430_LASTPOWERSTATEENTERED_MASK);
}
+static int omap4_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ u32 v;
+
+ v = pwrst __ffs(OMAP4430_LOGICRETSTATE_MASK);
+ prm_rmw_mod_reg_bits(OMAP4430_LOGICRETSTATE_MASK, v,
+ pwrdm-prcm_offs, OMAP4_PM_PWSTCTRL);
+
+ return 0;
+}
+
+static int omap4_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP4_PM_PWSTST,
+ OMAP4430_LOGICSTATEST_MASK);
+}
+
+static int omap4_pwrdm_read_logic_retst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP4_PM_PWSTCTRL,
+ OMAP4430_LOGICRETSTATE_MASK);
+}
+
struct pwrdm_functions omap4_pwrdm_functions = {
.pwrdm_set_next_pwrst = omap4_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = omap4_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap4_pwrdm_read_prev_pwrst,
+ .pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
+ .pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
};
diff --git a/arch/arm/plat-omap/powerdomain.c
b/arch/arm/plat-omap/powerdomain.c
index 73d6dad..9177fbb 100644
--- a/arch/arm/plat-omap/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -531,7 +531,7 @@ int pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
{
- u32 v;
+ int ret = -EINVAL;
if (!pwrdm)
return -EINVAL;
@@ -542,17 +542,10 @@ int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8
Re: [PATCH 5/6] OMAP: powerdomain: Arch specific funcs for mem control
Hi Rajendra,
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_mem_onst
.pwrdm_set_mem_retst
.pwrdm_read_mem_pwrst
.pwrdm_read_prev_mem_pwrst
.pwrdm_read_mem_retst
.pwrdm_clear_all_prev_pwrst
.pwrdm_enable_hdwr_sar
.pwrdm_disable_hdwr_sar
.pwrdm_wait_transition
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/powerdomains.c | 114
arch/arm/mach-omap2/powerdomains.h |5 +
arch/arm/mach-omap2/powerdomains2xxx.c | 129 ++
arch/arm/mach-omap2/powerdomains44xx.c | 87 +
arch/arm/plat-omap/powerdomain.c | 306
++--
6 files changed, 391 insertions(+), 252 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomains.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5f843fc..87a73b7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
\
- common.o
+ common.o powerdomains.o
Please move this down to the newly-created Powerdomains section of the
Makefile.
omap-2-3-common = irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/powerdomains.c
b/arch/arm/mach-omap2/powerdomains.c
new file mode 100644
index 000..876bebe
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains.c
Maybe call this file 'powerdomain-common.c' to be similar to file names
like prcm-common.c ?
@@ -0,0 +1,114 @@
+/*
+ * linux/arch/arm/mach-omap2/powerdomains.c
+ * Contains common powerdomain framework functions
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Derived from mach-omap2/powerdomain.c written by Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/errno.h
+#include linux/kernel.h
+#include pm.h
+#include cm.h
+#include cm-regbits-34xx.h
+#include cm-regbits-44xx.h
+#include prm-regbits-34xx.h
+#include prm-regbits-44xx.h
+
+/*
+ * OMAP3 and OMAP4 specific register bit initialisations
+ * Notice that the names here are not according to each power
+ * domain but the bit mapping used applies to all of them
+ */
+/* OMAP3 and OMAP4 Memory Onstate Masks (common across all power domains) */
+#define OMAP_MEM0_ONSTATE_MASK OMAP3430_SHAREDL1CACHEFLATONSTATE_MASK
+#define OMAP_MEM1_ONSTATE_MASK OMAP3430_L1FLATMEMONSTATE_MASK
+#define OMAP_MEM2_ONSTATE_MASK OMAP3430_SHAREDL2CACHEFLATONSTATE_MASK
+#define OMAP_MEM3_ONSTATE_MASK OMAP3430_L2FLATMEMONSTATE_MASK
+#define OMAP_MEM4_ONSTATE_MASK OMAP4430_OCP_NRET_BANK_ONSTATE_MASK
+
+/* OMAP3 and OMAP4 Memory Retstate Masks (common across all power domains) */
+#define OMAP_MEM0_RETSTATE_MASK OMAP3430_SHAREDL1CACHEFLATRETSTATE_MASK
+#define OMAP_MEM1_RETSTATE_MASK OMAP3430_L1FLATMEMRETSTATE_MASK
+#define OMAP_MEM2_RETSTATE_MASK OMAP3430_SHAREDL2CACHEFLATRETSTATE_MASK
+#define OMAP_MEM3_RETSTATE_MASK OMAP3430_L2FLATMEMRETSTATE_MASK
+#define OMAP_MEM4_RETSTATE_MASK OMAP4430_OCP_NRET_BANK_RETSTATE_MASK
+
+/* OMAP3 and OMAP4 Memory Status bits */
+#define OMAP_MEM0_STATEST_MASK OMAP3430_SHAREDL1CACHEFLATSTATEST_MASK
+#define OMAP_MEM1_STATEST_MASK OMAP3430_L1FLATMEMSTATEST_MASK
+#define OMAP_MEM2_STATEST_MASK OMAP3430_SHAREDL2CACHEFLATSTATEST_MASK
+#define OMAP_MEM3_STATEST_MASK OMAP3430_L2FLATMEMSTATEST_MASK
+#define OMAP_MEM4_STATEST_MASK OMAP4430_OCP_NRET_BANK_STATEST_MASK
+
+int _get_mem_bank_onstate_mask(u8 bank);
+int _get_mem_bank_retst_mask(u8 bank);
+int _get_mem_bank_stst_mask(u8 bank);
+
+/* Common Internal functions used across OMAP rev's*/
+int _get_mem_bank_onstate_mask(u8 bank)
+{
+ switch (bank) {
+ case 0:
+ return OMAP_MEM0_ONSTATE_MASK;
+ case 1:
+ return OMAP_MEM1_ONSTATE_MASK;
+ case 2:
+ return OMAP_MEM2_ONSTATE_MASK;
+ case 3:
+ return OMAP_MEM3_ONSTATE_MASK;
+ case 4:
+ return OMAP_MEM4_ONSTATE_MASK;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
+ }
+ return 0;
+}
+
+int _get_mem_bank_retst_mask(u8 bank)
+{
+ switch (bank) {
+ case 0:
+ return OMAP_MEM0_RETSTATE_MASK;
+ case 1:
+ return OMAP_MEM1_RETSTATE_MASK;
+ case 2:
+ return
Re: [PATCH 6/6] OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst
Hi
On Tue, 16 Nov 2010, Rajendra Nayak wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4430 ES2 has additional bitfields in PWRSTST register which help
identify the previous power state entered by the powerdomain.
Add pwrdm_clear_all_prev_pwrst api to support this.
OMAP3 has these also. Please add a similar function for OMAP3.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains44xx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx.c
b/arch/arm/mach-omap2/powerdomains44xx.c
index 79be2cd..0414e6a 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.c
+++ b/arch/arm/mach-omap2/powerdomains44xx.c
@@ -45,6 +45,14 @@ static int omap4_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
OMAP4430_LASTPOWERSTATEENTERED_MASK);
}
+static int omap4_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm)
+{
+ prm_rmw_mod_reg_bits(OMAP4430_LASTPOWERSTATEENTERED_MASK,
+ 0x3 OMAP4430_LASTPOWERSTATEENTERED_SHIFT,
Please just use OMAP4430_LASTPOWERSTATEENTERED_MASK here again rather
than 0x3 OMAP4430_LASTPOWERSTATEENTERED_SHIFT. This avoids introducing
a magic constant here.
+ pwrdm-prcm_offs, OMAP4_PM_PWSTST);
+ return 0;
+}
+
static int omap4_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
{
prm_rmw_mod_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
@@ -154,6 +162,7 @@ struct pwrdm_functions omap4_pwrdm_functions = {
.pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = omap4_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap4_pwrdm_read_prev_pwrst,
+ .pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_lowpwrstchange = omap4_pwrdm_set_lowpwrstchange,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
--
1.7.0.4
- 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: [PATCH 0/6] Split powerdomain framework into plat specific/independent
Hi Rajendra, As you've seen, I just did another review pass on these. All of the review comments are pretty minor, although some of them will require moving some of the functions to different files, mostly due to OMAP3 functions being present in an OMAP2xxx file. Once those changes are made and the series reposted, I think these will be good to merge. regards - 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
