[PATCH] OMAP: DMA: Add API for setting channel dest addr
The new API - omap_set_dma_dst_pos(int lch, int value) is added
for setting channel destination address in CPC/CDAC register
Cc: Tony Lindgren t...@atomide.com
Cc: S, Venkatraman svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/plat-omap/dma.c | 17 +
arch/arm/plat-omap/include/plat/dma.h |1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..9a2a5c4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1109,6 +1109,23 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
}
EXPORT_SYMBOL(omap_get_dma_dst_pos);
+/**
+ * omap_set_dma_dst_pos() - Set DMA channel destination address
+ * @arg1: lch DMA logical channel number
+ * @arg2: valueValue to write into CDAC register
+ *
+ * Writes value into the register CPC/CDAC
+ */
+void omap_set_dma_dst_pos(int lch, int value)
+{
+ if (cpu_is_omap15xx())
+ dma_write(CPC(lch), value);
+ else
+ dma_write(CDAC(lcd), value);
+
+}
+EXPORT_SYMBOL(omap_set_dma_dst_pos);
+
int omap_get_dma_active_status(int lch)
{
return (dma_read(CCR(lch)) OMAP_DMA_CCR_EN) != 0;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..3b6e43e 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -509,6 +509,7 @@ extern int omap_set_dma_callback(int lch,
void *data);
extern dma_addr_t omap_get_dma_src_pos(int lch);
extern dma_addr_t omap_get_dma_dst_pos(int lch);
+extern void omap_set_dma_dst_pos(int lch, int value);
extern void omap_clear_dma(int lch);
extern int omap_get_dma_active_status(int lch);
extern int omap_dma_running(void);
--
1.6.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] OMAP: DMA: Add API for setting channel dest addr
Manju,
Is this patch can build?
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
Manjunath Kondaiah
Sent: Tuesday, March 02, 2010 3:46 PM
To: linux-omap@vger.kernel.org
Cc: G, Manjunath Kondaiah; Tony Lindgren; S, Venkatraman; Raja, Govindraj
Subject: [PATCH] OMAP: DMA: Add API for setting channel dest addr
The new API - omap_set_dma_dst_pos(int lch, int value) is added
for setting channel destination address in CPC/CDAC register
Cc: Tony Lindgren t...@atomide.com
Cc: S, Venkatraman svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/plat-omap/dma.c | 17 +
arch/arm/plat-omap/include/plat/dma.h |1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..9a2a5c4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1109,6 +1109,23 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
}
EXPORT_SYMBOL(omap_get_dma_dst_pos);
+/**
+ * omap_set_dma_dst_pos() - Set DMA channel destination address
+ * @arg1: lch DMA logical channel number
+ * @arg2: valueValue to write into CDAC register
+ *
+ * Writes value into the register CPC/CDAC
+ */
+void omap_set_dma_dst_pos(int lch, int value)
+{
+ if (cpu_is_omap15xx())
+ dma_write(CPC(lch), value);
+ else
+ dma_write(CDAC(lcd), value);
Should be dma_write(CDAC(lch), value);
+
+}
+EXPORT_SYMBOL(omap_set_dma_dst_pos);
+
int omap_get_dma_active_status(int lch)
{
return (dma_read(CCR(lch)) OMAP_DMA_CCR_EN) != 0;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..3b6e43e 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -509,6 +509,7 @@ extern int omap_set_dma_callback(int lch,
void *data);
extern dma_addr_t omap_get_dma_src_pos(int lch);
extern dma_addr_t omap_get_dma_dst_pos(int lch);
+extern void omap_set_dma_dst_pos(int lch, int value);
extern void omap_clear_dma(int lch);
extern int omap_get_dma_active_status(int lch);
extern int omap_dma_running(void);
--
1.6.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
--
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: [PATCHv6 9/9] OMAP3: PM: Added support for suspending to INACTIVE state
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:43
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 9/9] OMAP3: PM: Added support for
suspending to INACTIVE state
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
With the new support functions this is now possible.
Suspending to INACTIVE
is useful for testing purposes.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index cdbedcf..41d6cc3 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -633,11 +633,12 @@ int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state)
if (pwrdm == NULL || IS_ERR(pwrdm))
return -EINVAL;
-while (!(pwrdm-pwrsts (1 state))) {
-if (state == PWRDM_POWER_OFF)
-return ret;
-state--;
-}
The comment above set_pwrdm_state() says only ON RET are supported.
Please update that comment as well.
True, ancient info there. OFF for example has been supported for ages already.
+if (state != PWRDM_POWER_INACTIVE)
+while (!(pwrdm-pwrsts (1 state))) {
+if (state == PWRDM_POWER_OFF)
+return ret;
+state--;
+}
I think all powerdomains can be inactive right?
Yes.
I think it would be cleaner to just have all the pwrdm-pwrsts fields
include intactive as a valid option.
Something like the patch below. IIRC, you did something like this in
one of the earlier versions of the patch.
Yeah, something like this was done previously, however Paul did not like the
idea of changing the generic powerdomain code too much so I dropped it
completely. It is now done only via the support functions in patch #1, and only
done for the powerdomains that actually need it for the cpuidle
(mpu/core/neon.) It would be possible to add support for the rest of the
powerdomains also, but I decided to drop this in favor of getting the patch set
in.
Kevin
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index a1ecd47..c692472 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -31,17 +31,17 @@
#define PWRDM_MAX_PWRSTS 4
/* Powerdomain allowable state bitfields */
-#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | \
+#define PWRSTS_ON ((1 PWRDM_POWER_INACTIVE) | \
(1 PWRDM_POWER_ON))
+#define PWRSTS_OFF_ON ((1 PWRDM_POWER_OFF) | PWRSTS_ON)
+
#define PWRSTS_OFF_RET((1 PWRDM_POWER_OFF) | \
(1 PWRDM_POWER_RET))
-#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET) | \
- (1 PWRDM_POWER_ON))
-
-#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 PWRDM_POWER_ON))
+#define PWRSTS_RET_ON ((1 PWRDM_POWER_RET) | PWRSTS_ON)
+#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | PWRSTS_ON)
/* Powerdomain flags */
#define PWRDM_HAS_HDWR_SAR(1 0) /* hardware
save-and-restore support */
--
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: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state hacking from omap_sram_idle
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:32
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 4/9] OMAP3: PM: Removed pwrdm state
hacking from omap_sram_idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Following hacks will be moved inside cpuidle in subsequent patch:
- CAM domain prevents idle completely
- PER should not go OFF if core remains active
This simplifies the design and allows cpuidle to keep better
track of which
power states system will actually enter.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
I think this should be combined with PATCH 7. IOW, the removal and
re-addition should be in the same patch.
Ok, will change this.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 19 ++-
1 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index c2d80fc..cdbedcf 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,7 +93,6 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -373,7 +372,6 @@ void omap_sram_idle(void)
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
-int per_state_modified = 0;
if (!_omap_sram_idle)
return;
@@ -411,20 +409,11 @@ void omap_sram_idle(void)
core_next_state = omap3_pwrdm_read_next_pwrst(core_pwrdm);
if (per_next_state PWRDM_POWER_ON) {
omap2_gpio_prepare_for_idle(per_next_state);
-if (per_next_state == PWRDM_POWER_OFF) {
-if (core_next_state == PWRDM_POWER_ON) {
-per_next_state = PWRDM_POWER_RET;
-pwrdm_set_next_pwrst(per_pwrdm,
per_next_state);
-per_state_modified = 1;
-} else
-omap3_per_save_context();
-}
+if (per_next_state == PWRDM_POWER_OFF)
+omap3_per_save_context();
omap_uart_prepare_idle(2);
}
-if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
-omap2_clkdm_deny_idle(mpu_pwrdm-pwrdm_clkdms[0]);
-
/*
* Disable smartreflex before entering WFI.
* Only needed if we are going to enter retention or off.
@@ -554,8 +543,6 @@ void omap_sram_idle(void)
}
omap2_gpio_resume_after_idle();
omap_uart_resume_idle(2);
-if (per_state_modified)
-pwrdm_set_next_pwrst(per_pwrdm,
PWRDM_POWER_OFF);
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -564,7 +551,6 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
-
pwrdm_post_transition();
}
@@ -1239,7 +1225,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
per_pwrdm = pwrdm_lookup(per_pwrdm);
core_pwrdm = pwrdm_lookup(core_pwrdm);
-cam_pwrdm = pwrdm_lookup(cam_pwrdm);
neon_clkdm = clkdm_lookup(neon_clkdm);
mpu_clkdm = clkdm_lookup(mpu_clkdm);
--
1.5.4.3
--
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: [PATCHv6 1/9] OMAP3: PM: Added support functions for omap3 pwrdm handling
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:17
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 1/9] OMAP3: PM: Added support functions
for omap3 pwrdm handling
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Added omap3_pwrdm_set_next_pwrst and
omap3_pwrdm_read_next_pwrst. These
functions add support for INACTIVE and ON states to the standard OMAP
powerdomain functions, and add caching logic for the next
state. These
functions are used in subsequent patches to simplify the
logic of the idle
loop.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm34xx.c | 60
+-
2 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 75aa685..1d9a740 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -67,6 +67,8 @@ static inline void omap3_pm_init_vc(struct
prm_setup_vc *setup_vc)
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain
*pwrdm, int state);
+extern int omap3_pwrdm_set_next_pwrst(struct powerdomain
*pwrdm, u8 pwrst);
+extern int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm);
extern u32 wakeup_timer_seconds;
extern struct omap_dm_timer *gptimer_wakeup;
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 1359ec9..f20d3d8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -576,6 +576,64 @@ int omap3_can_sleep(void)
return 1;
}
+struct powerdomain_data {
+u8 next_state;
+u8 init_done;
+};
+
+static struct powerdomain_data mpu_pwrdm_data;
+static struct powerdomain_data core_pwrdm_data;
+static struct powerdomain_data neon_pwrdm_data;
+
+static struct powerdomain_data *get_pwrdm_data(struct
powerdomain *pwrdm)
+{
+if (pwrdm == mpu_pwrdm)
+return mpu_pwrdm_data;
+else if (pwrdm == core_pwrdm)
+return core_pwrdm_data;
+else if (pwrdm == neon_pwrdm)
+return neon_pwrdm_data;
+return NULL;
+}
+
+int omap3_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
I think this func should be documented along the lines of the
changelog.
It should describe the caching and the fact that 'INACTIVE' is a state
that can be read, but not written.
Ok, will do the change.
+{
+struct powerdomain_data *data = get_pwrdm_data(pwrdm);
+u8 prg_pwrst;
+
+if (!data)
+return pwrdm_set_next_pwrst(pwrdm, pwrst);
+
+if (!data-init_done)
+data-init_done = 1;
Not sure I follow the purpose of the 'init_done' flag here,
but I'm having
an averse reaction to it.
init_done actually means if the cache is valid or not. If not, we ignore the
current cached state. Another way of doing this would be to initialize all
values at proper point during boot by reading from HW, or just put the HW reset
values to the cache during compile time. The cache validity bit is needed in
the read_next_pwrst code also below.
+else if (data-next_state == pwrst)
+return 0;
+
+if (pwrst == PWRDM_POWER_INACTIVE)
+prg_pwrst = PWRDM_POWER_ON;
+else
+prg_pwrst = pwrst;
+
+pwrdm_set_next_pwrst(pwrdm, prg_pwrst);
+
+if (pwrst == PWRDM_POWER_ON)
+omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+else
+omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+
+data-next_state = pwrst;
+return 0;
+}
+
+int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
+{
+struct powerdomain_data *data = get_pwrdm_data(pwrdm);
+
+if (!data || !data-init_done)
+return pwrdm_read_next_pwrst(pwrdm);
+return data-next_state;
+}
+
/* This sets pwrdm state (other than mpu core. Currently only ON
* RET are supported. Function is assuming that clkdm doesn't have
* hw_sup mode enabled. */
@@ -604,7 +662,7 @@ int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state)
pwrdm_wait_transition(pwrdm);
}
-ret = pwrdm_set_next_pwrst(pwrdm, state);
+ret = omap3_pwrdm_set_next_pwrst(pwrdm, state);
if (ret) {
printk(KERN_ERR Unable to set state of
powerdomain: %s\n,
pwrdm-name);
--
1.5.4.3
--
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
[PATCHv3 0/4] Regulator: OMAP: Removing common code for TWL4030 from OMAP3-board-evms
Sending version 3 of this patch-set after rebasing it against the for-next branch in the linux-omap tree. The previous series can be found at: http://marc.info/?l=linux-omapm=126328763822497w=2 This patch set is created to clean up various OMAP3-board-evm files and remove common TWL4030 specific regulator suplies and init data structs. These structures are instead placed in a new generic file - twl4030-pmic.c - and are referenced from the OMAP3 board-evm files depending on the platform requirements. Regulator having specific supplies or init data structs are not changed in their respective board-evms. uImage built and tested for OMAP3EVM; compile-tested for SDP3430 and all OMAP platforms (using omap3_defconfig). Anuj Aggarwal (4): Regulator: OMAP: Creating TWL4030 file having supplies init data Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs Regulator: OMAP: Kconfig modified to select TWL4030 for OMAP3-platforms Regulator: OMAP: Use common regulator supplies and init data structs arch/arm/mach-omap2/Kconfig | 20 +++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-3430sdp.c | 135 ++-- arch/arm/mach-omap2/board-cm-t35.c | 47 +-- arch/arm/mach-omap2/board-igep0020.c | 24 +--- arch/arm/mach-omap2/board-ldp.c | 24 +--- arch/arm/mach-omap2/board-omap3beagle.c | 47 +-- arch/arm/mach-omap2/board-omap3evm.c | 47 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 47 +-- arch/arm/mach-omap2/board-overo.c| 23 +--- arch/arm/mach-omap2/board-zoom-peripherals.c | 71 +-- arch/arm/mach-omap2/twl4030-pmic.c | 175 ++ arch/arm/mach-omap2/twl4030-pmic.h | 34 + 13 files changed, 277 insertions(+), 418 deletions(-) create mode 100644 arch/arm/mach-omap2/twl4030-pmic.c create mode 100644 arch/arm/mach-omap2/twl4030-pmic.h -- 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
[PATCHv3 2/4] Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs
Kconfig is modified for OMAP3 EVM so that user can choose the appropriate PMIC (currently only TWL4030). Config options for other PMICs will be added later on. Makefile is modified so that twl4030-pmic.c gets compiled for the platforms having TWL4030 as the PMIC. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Kconfig |9 + arch/arm/mach-omap2/Makefile |1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..1974dda 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -77,6 +77,15 @@ config MACH_OMAP3EVM depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB +config PMIC_TWL4030 + bool TWL4030/TPS65950 Power Module + default y + select TWL4030_CORE + select REGULATOR_TWL4030 if REGULATOR + help + Say yes here if you are using the TWL4030/TPS65950 based power module + for the EVM boards. + config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 2069fb3..c33e24d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -137,6 +137,7 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ hsmmc.o +obj-$(CONFIG_PMIC_TWL4030) += twl4030-pmic.o obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o -- 1.6.2.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
[PATCHv3 3/4] Regulator: OMAP: Kconfig modified to select TWL4030 for OMAP3-platforms
Kconfig is modified so that PMIC TWL4030 is automatically selected for platforms using it. It is required to compile twl4030-pmic.c in the build. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Kconfig | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 1974dda..f58f321 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -57,6 +57,7 @@ config MACH_OMAP3_BEAGLE bool OMAP3 BEAGLE board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config MACH_DEVKIT8000 bool DEVKIT8000 board @@ -66,16 +67,19 @@ config MACH_OMAP_LDP bool OMAP3 LDP board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config MACH_OVERO bool Gumstix Overo board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config MACH_OMAP3EVM bool OMAP 3530 EVM board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config PMIC_TWL4030 bool TWL4030/TPS65950 Power Module @@ -100,11 +104,13 @@ config MACH_OMAP3_TOUCHBOOK bool OMAP3 Touch Book depends on ARCH_OMAP3 select BACKLIGHT_CLASS_DEVICE + select PMIC_TWL4030 config MACH_OMAP_3430SDP bool OMAP 3430 SDP board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config MACH_NOKIA_N800 bool @@ -131,27 +137,32 @@ config MACH_OMAP_ZOOM2 bool OMAP3 Zoom2 board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config MACH_OMAP_ZOOM3 bool OMAP3630 Zoom3 board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBP + select PMIC_TWL4030 config MACH_CM_T35 bool CompuLab CM-T35 module depends on ARCH_OMAP3 select OMAP_PACKAGE_CUS select OMAP_MUX + select PMIC_TWL4030 config MACH_IGEP0020 bool IGEP v2 board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB + select PMIC_TWL4030 config MACH_OMAP_3630SDP bool OMAP3630 SDP board depends on ARCH_OMAP3 select OMAP_PACKAGE_CBP + select PMIC_TWL4030 config MACH_OMAP_4430SDP bool OMAP 4430 SDP board -- 1.6.2.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
[PATCHv3 4/4] Regulator: OMAP: Use common regulator supplies and init data structs
Removing the common supplies and regulator init data structs for various
OMAP3 platforms and referring them from the twl4030 common file.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 135 ++---
arch/arm/mach-omap2/board-cm-t35.c | 47 +
arch/arm/mach-omap2/board-igep0020.c | 24 +
arch/arm/mach-omap2/board-ldp.c | 24 +
arch/arm/mach-omap2/board-omap3beagle.c | 47 +
arch/arm/mach-omap2/board-omap3evm.c | 47 +
arch/arm/mach-omap2/board-omap3touchbook.c | 47 +
arch/arm/mach-omap2/board-overo.c| 23 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 71 ++
9 files changed, 47 insertions(+), 418 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f312b15..e414371 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -47,6 +47,7 @@
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
#include pm.h
+#include twl4030-pmic.h
#define CONFIG_DISABLE_HFCLK 1
@@ -365,18 +366,6 @@ static struct omap2_hsmmc_info mmc[] = {
{} /* Terminator */
};
-static struct regulator_consumer_supply sdp3430_vmmc1_supply = {
- .supply = vmmc,
-};
-
-static struct regulator_consumer_supply sdp3430_vsim_supply = {
- .supply = vmmc_aux,
-};
-
-static struct regulator_consumer_supply sdp3430_vmmc2_supply = {
- .supply = vmmc,
-};
-
static int sdp3430_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -390,9 +379,9 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
/* link regulators to MMC adapters ... we know the
* regulators will be set up only *after* we return.
*/
- sdp3430_vmmc1_supply.dev = mmc[0].dev;
- sdp3430_vsim_supply.dev = mmc[0].dev;
- sdp3430_vmmc2_supply.dev = mmc[1].dev;
+ twl4030_vmmc1_supply.dev = mmc[0].dev;
+ twl4030_vsim_supply.dev = mmc[0].dev;
+ twl4030_vmmc2_supply.dev = mmc[1].dev;
/* gpio + 7 is sub_lcd_en_bkl (output/PWM1) */
gpio_request(gpio + 7, sub_lcd_en_bkl);
@@ -422,108 +411,6 @@ static struct twl4030_madc_platform_data
sdp3430_madc_data = {
.irq_line = 1,
};
-/*
- * Apply all the fixed voltages since most versions of U-Boot
- * don't bother with that initialization.
- */
-
-/* VAUX1 for mainboard (irda and sub-lcd) */
-static struct regulator_init_data sdp3430_vaux1 = {
- .constraints = {
- .min_uV = 280,
- .max_uV = 280,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-/* VAUX2 for camera module */
-static struct regulator_init_data sdp3430_vaux2 = {
- .constraints = {
- .min_uV = 280,
- .max_uV = 280,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-/* VAUX3 for LCD board */
-static struct regulator_init_data sdp3430_vaux3 = {
- .constraints = {
- .min_uV = 280,
- .max_uV = 280,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-/* VAUX4 for OMAP VDD_CSI2 (camera) */
-static struct regulator_init_data sdp3430_vaux4 = {
- .constraints = {
- .min_uV = 180,
- .max_uV = 180,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
-};
-
-/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
-static struct regulator_init_data sdp3430_vmmc1 = {
- .constraints = {
- .min_uV = 185,
- .max_uV = 315,
- .valid_modes_mask =
RE: [PATCH] OMAP: DMA: Add API for setting channel dest addr
Santosh, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, March 02, 2010 3:35 PM To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org Cc: Tony Lindgren; S, Venkatraman; Raja, Govindraj Subject: RE: [PATCH] OMAP: DMA: Add API for setting channel dest addr Manju, Is this patch can build? It looks like after generating patch, I did minor changes related to Description directly in the patch. While doing so, I goofed up lcd-lch. Thanks for figuring it out. -Manjunath -- 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: prcm: Use logical OR instead of bitwise OR
On Mon, 1 Mar 2010, Rajendra Nayak wrote: This patch fixes usage of bitwise OR in if conditions, and instead uses logical OR. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Abhijit Pagare abhijitpag...@ti.com Thanks, queued for .34-rcX. - 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: [PATCHv2 1/4] Regulator: OMAP: Creating TWL4030 file having supplies init data
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 05, 2010 7:10 AM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk Subject: Re: [PATCHv2 1/4] Regulator: OMAP: Creating TWL4030 file having supplies init data Hi, * Anuj Aggarwal anuj.aggar...@ti.com [100112 01:12]: A new file for TWL4030/TPS65950 is created which has common supplies and regulator init data structures. They will be referenced from the various board-evm files depending upon the EVM requirements, using the twl4030-pmic.h header file. Looks like this series needs to be rebased on omap-for-linus branch in the linux-omap tree. Please also check that the patches apply against the current for-next branch in the linux-omap tree. Also, please check that each patch in the series builds (and boots) with arch/arm/config/omap3_defconfig. Tony, I have rebased the patch set (version 3) against for-next tip. I have also checked that each patch builds (and boots) with omap3_defconfig individually. Please pull. -- 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] OMAP: Fixing build warning with omap3_defconfig
Fixes the below build warning when compiled with omap3_defconfig:
CC arch/arm/mach-omap2/board-am3517evm.o
In file included from arch/arm/mach-omap2/board-am3517evm.c:23:
include/linux/i2c/pca953x.h:14: warning: 'struct i2c_client' declared
inside parameter list
include/linux/i2c/pca953x.h:14: warning: its scope is only this definition
or declaration, which is probably not what you want
include/linux/i2c/pca953x.h:17: warning: 'struct i2c_client' declared inside
parameter list
CC arch/arm/mach-omap2/usb-musb.o
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
include/linux/i2c/pca953x.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c/pca953x.h b/include/linux/i2c/pca953x.h
index 81736d6..6c8f853 100644
--- a/include/linux/i2c/pca953x.h
+++ b/include/linux/i2c/pca953x.h
@@ -1,4 +1,5 @@
/* platform data for the PCA9539 16-bit I/O expander driver */
+#include linux/i2c.h
struct pca953x_platform_data {
/* number of the first GPIO */
--
1.6.2.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] OMAP: Zoom3: Fix Zoom3 booting issue
The commit id 5550bc33a1a9002976022cc794fe8c52ad9a0021 seems to be broken
zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630.
But, it looks like OMAP3630 UART4 interface and functional clock nodes needs
to be added for omap3630. Thus limiting no. of UART's for 3630 to 3 to prevent
boot up issues until clock nodes are added for UART4 on OMAP3630.
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..ac22a4e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -764,7 +764,12 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ /* Limit no.of UART ports to three for OMAP3630 since
+* clock nodes are yet to be updated for 3630 UART4.
+* TODO: update clock nodes for 3630 UART4 and then enable
+* check for !(cpu_is_omap3630())
+*/
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.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
[PATCH v2] OMAP: DMA: Add API for setting channel dest addr
The new API - omap_set_dma_dst_pos(int lch, int value) is added
for setting channel destination address in CPC/CDAC register
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: S, Venkatraman svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/plat-omap/dma.c | 17 +
arch/arm/plat-omap/include/plat/dma.h |1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..c73f11a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1109,6 +1109,23 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
}
EXPORT_SYMBOL(omap_get_dma_dst_pos);
+/**
+ * omap_set_dma_dst_pos() - Set DMA channel destination address
+ * @arg1: lch DMA logical channel number
+ * @arg2: valueValue to write into CDAC register
+ *
+ * Writes value into the register CPC/CDAC
+ */
+void omap_set_dma_dst_pos(int lch, int value)
+{
+ if (cpu_is_omap15xx())
+ dma_write(value, CPC(lch));
+ else
+ dma_write(value, CDAC(lch));
+
+}
+EXPORT_SYMBOL(omap_set_dma_dst_pos);
+
int omap_get_dma_active_status(int lch)
{
return (dma_read(CCR(lch)) OMAP_DMA_CCR_EN) != 0;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..3b6e43e 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -509,6 +509,7 @@ extern int omap_set_dma_callback(int lch,
void *data);
extern dma_addr_t omap_get_dma_src_pos(int lch);
extern dma_addr_t omap_get_dma_dst_pos(int lch);
+extern void omap_set_dma_dst_pos(int lch, int value);
extern void omap_clear_dma(int lch);
extern int omap_get_dma_active_status(int lch);
extern int omap_dma_running(void);
--
1.6.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] serial: Add OMAP high-speed UART driver.
On Tue, Mar 2, 2010 at 12:22 PM, Tony Lindgren t...@atomide.com wrote: * G, Manjunath Kondaiah manj...@ti.com [100301 22:24]: + up-uart_dma.prev_rx_dma_pos = up-uart_dma.rx_buf_dma_phys; + if (cpu_is_omap44xx()) + omap_writel(0, OMAP44XX_DMA4_BASE + + OMAP_DMA4_CDAC(up-uart_dma.rx_dma_channel)); + else + omap_writel(0, OMAP34XX_DMA4_BASE + + OMAP_DMA4_CDAC(up-uart_dma.rx_dma_channel)); NAK. Please don't use omap_read/write for for new code. And do not tinker with the omap hardware registers directly in the driver. This needs to be done properly in arch/arm/plat-omap/dma.c instead. Thanks for the suggestion. Currently, dma_read/dma_write are #define's in dma.c which cannot be accessed outside dma.c. I don't see any API's in dma.c for setting required value for this register? Hmm isn't this the same as omap_get_dma_dst_pos(int lch)? If you're trying do something that's not in dma.c, we can add a new function for it. The omap_get_dma_dst_pos(int lch) is for read operation in CDAC register. But, We need to write required value into CDAC register. For this, I propose: omap_set_dma_dst_pos(int lch, int value) which does not exist in current dma driver. OK, it that's needed. Tony -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. Simple wrapper APIs doing get / set on individual DMA registers is as difficult to understand as omap_read / omap_write, IMHO. Best regards, Venkat. -- 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 v2] OMAP: DMA: Add API for setting channel dest addr
Manjunath,
On Tue, Mar 2, 2010 at 7:06 PM, Manjunatha GK manj...@ti.com wrote:
The new API - omap_set_dma_dst_pos(int lch, int value) is added
for setting channel destination address in CPC/CDAC register
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: S, Venkatraman svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/plat-omap/dma.c | 17 +
arch/arm/plat-omap/include/plat/dma.h | 1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..c73f11a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1109,6 +1109,23 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
}
EXPORT_SYMBOL(omap_get_dma_dst_pos);
+/**
+ * omap_set_dma_dst_pos() - Set DMA channel destination address
+ * @arg1: lch DMA logical channel number
+ * @arg2: value Value to write into CDAC register
+ *
+ * Writes value into the register CPC/CDAC
+ */
+void omap_set_dma_dst_pos(int lch, int value)
+{
+ if (cpu_is_omap15xx())
+ dma_write(value, CPC(lch));
+ else
+ dma_write(value, CDAC(lch));
+
+}
+EXPORT_SYMBOL(omap_set_dma_dst_pos);
+
int omap_get_dma_active_status(int lch)
{
return (dma_read(CCR(lch)) OMAP_DMA_CCR_EN) != 0;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..3b6e43e 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -509,6 +509,7 @@ extern int omap_set_dma_callback(int lch,
void *data);
extern dma_addr_t omap_get_dma_src_pos(int lch);
extern dma_addr_t omap_get_dma_dst_pos(int lch);
+extern void omap_set_dma_dst_pos(int lch, int value);
extern void omap_clear_dma(int lch);
extern int omap_get_dma_active_status(int lch);
extern int omap_dma_running(void);
--
CDAC is not the destination address, as the API seems to suggest.
CDSA (Channel Destination Start Address) is.
CDAC is a running counter of the current transfer.
I propose to update the omap_start_dma to reset CDAC to 0 always.
Best regards,
Venkat.
--
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] serial: Add OMAP high-speed UART driver.
-Original Message- From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of Venkatraman S Sent: Tuesday, March 02, 2010 7:16 PM To: Tony Lindgren; G, Manjunath Kondaiah; Raja, Govindraj; Greg KH; linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: Re: [PATCH] serial: Add OMAP high-speed UART driver. On Tue, Mar 2, 2010 at 12:22 PM, Tony Lindgren t...@atomide.com wrote: * G, Manjunath Kondaiah manj...@ti.com [100301 22:24]: + up-uart_dma.prev_rx_dma_pos = up-uart_dma.rx_buf_dma_phys; + if (cpu_is_omap44xx()) + omap_writel(0, OMAP44XX_DMA4_BASE + + OMAP_DMA4_CDAC(up-uart_dma.rx_dma_channel)); + else + omap_writel(0, OMAP34XX_DMA4_BASE + + OMAP_DMA4_CDAC(up-uart_dma.rx_dma_channel)); NAK. Please don't use omap_read/write for for new code. And do not tinker with the omap hardware registers directly in the driver. This needs to be done properly in arch/arm/plat-omap/dma.c instead. Thanks for the suggestion. Currently, dma_read/dma_write are #define's in dma.c which cannot be accessed outside dma.c. I don't see any API's in dma.c for setting required value for this register? Hmm isn't this the same as omap_get_dma_dst_pos(int lch)? If you're trying do something that's not in dma.c, we can add a new function for it. The omap_get_dma_dst_pos(int lch) is for read operation in CDAC register. But, We need to write required value into CDAC register. For this, I propose: omap_set_dma_dst_pos(int lch, int value) which does not exist in current dma driver. OK, it that's needed. Tony -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. -Manjunath -- 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] serial: Add OMAP high-speed UART driver.
snip snip -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. It's needed only if some one is interested in that count. UART seems to using this counter where as other driver don't. Why do you think drivers need to know about counter value ? 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
RE: [PATCH] serial: Add OMAP high-speed UART driver.
Santosh, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, March 02, 2010 7:34 PM To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. snip snip -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. It's needed only if some one is interested in that count. UART seems to using this counter where as other driver don't. Why do you think drivers need to know about counter value ? Reading of non zero value(after reset to zero and enabling dma channel) from CDAC register indicates that, DMA transfer has started and user can rely on DMA4_CCENi and DMA4_CCFNi element and frame counters. If the CDAC value is zero even after starting DMA channel, indicates error. -Manjunath -- 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] serial: Add OMAP high-speed UART driver.
-Original Message- From: G, Manjunath Kondaiah Sent: Tuesday, March 02, 2010 8:34 PM To: Shilimkar, Santosh; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux- ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. Santosh, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, March 02, 2010 7:34 PM To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. snip snip -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. It's needed only if some one is interested in that count. UART seems to using this counter where as other driver don't. Why do you think drivers need to know about counter value ? Reading of non zero value(after reset to zero and enabling dma channel) from CDAC register indicates that, DMA transfer has started and user can rely on DMA4_CCENi and DMA4_CCFNi element and frame counters. If the CDAC value is zero even after starting DMA channel, indicates error. Not necessary. The DMA can still wait for the hw sync signal and the CDAC can remain 0 if the hw sync in not received. This will be any way returned by DMA error ( SYNC lost) This register was mainly suppose to be used for debug purposes. 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
[GIT PULL] OMAP DSS updates for 2.6.34
Hi Linus, Please pull the OMAP Display Subsystem patches below. - Couple of new panel drivers - Various small fixes and improvements - Multiple patches making the DSS device model more sane, moving the control from the DSS core driver to the panel drivers. This makes it possible for the panel drivers to fully control what is going on, instead of having to work with the limits imposed by the DSS core. Tomi The following changes since commit 13dda80e48439b446d0bc9bab34b91484bc8f533: Linus Torvalds (1): Merge branch 'davinci-for-linus' of git://git.kernel.org/.../khilman/linux-davinci are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-linus Aaro Koskinen (1): OMAP: DSS: Taal: fix error returns in taal_probe() Grazvydas Ignotas (1): OMAP: DSS: add TPO TD043MTEA1 panel Janusz Krzysztofik (2): omapfb: Fix 12-bit display (RGB444 color mode) handling omapfb: lcd_ams_delta: add support for contrast control Mike Rapoport (1): OMAP: DSS2: add Toppoly TDO35S panel Tomi Valkeinen (41): OMAP: DSS2: Improve Kconfig help texts OMAP: DSS2: enable VDDS_DSI when using DPI OMAP: 3430SDP: remove vdvi regulator OMAP: DSS2: OMAPFB: implement OMAPFB_GET_DISPLAY_INFO OMAP: DSS2: fix irq-stats compilation OMAP: DSS2: OMAPFB: Add omapfb_update_window prototype OMAP: DSS2: improve DSS clk src selection OMAP: DSS2: DSI: add dsi_bus_is_locked() OMAP: DSS2: DSI: add helpers for DCS read/write OMAP: DSS2: DSI: export dsi_vc_enable_hs() OMAP: DSS2: DSI: configure all DSI VCs OMAP: DSS2: DSI: remove dsi_vc_print_status() OMAP: DSS2: Check ctx loss count only when starting the first clock OMAP: DSS2: remove sub-panel system OMAP: DSS2: fix driver probe error handling OMAP: DSS2: OMAPFB: fix dssdev cleanup on error OMAP: DSS2: OMAPFB: fix cleanup on dssdev enable error OMAP: DSS2: fix get_dsi/dispc_clk_source() usage OMAP: DSS2: DSI: change DSI bus_lock to semaphore OMAP: DSS2: DSI: remove auto-update perf measurement OMAP: DSS2: move run_test() OMAP: DSS2: move memory_read() OMAP: DSS2: move set/get_mirror() OMAP: DSS2: move get/set_rotate() OMAP: DSS2: move wait_vsync() OMAP: DSS2: move enable/disable_channel to overlay manager OMAP: DSS2: move get_resolution() OMAP: DSS2: move get_recommended_bpp() OMAP: DSS2: move enable/get_te() OMAP: DSS2: move set/get_update_mode() OMAP: DSS2: move update() and sync() OMAP: DSS2: move enable/disable/suspend/resume OMAP: DSS2: move set/get_wss() OMAP: DSS2: move timing functions OMAP: DSS2: DSI: remove external TE support OMAP: DSS2: OMAPFB: Remove FB_OMAP2_FORCE_AUTO_UPDATE OMAP: DSS2: DSI: add dsi_vc_dcs_read_2() helper OMAP: DSS2: TPO-TD03MTEA1: fix function names OMAP: DSS2: DSI: add error prints OMAP: DSS2: Taal: Fix ESD check OMAP: DSS2: Taal: Fix TE when resuming Vaibhav Hiremath (1): OMAP: DSS2: Add Sharp LQ043T1DG01 panel driver Ville Syrjälä (2): OMAP: DSS2: OMAPFB: install omapfb.h OMAP: DSS2: OMAPFB: Constify some function parameters arch/arm/mach-omap2/board-3430sdp.c|4 - arch/arm/plat-omap/include/plat/display.h | 117 ++- drivers/video/omap/lcd_ams_delta.c | 93 ++- drivers/video/omap/omapfb_main.c |7 +- drivers/video/omap2/displays/Kconfig | 18 + drivers/video/omap2/displays/Makefile |3 + drivers/video/omap2/displays/panel-generic.c | 56 +- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 159 +++ .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 77 +- drivers/video/omap2/displays/panel-taal.c | 253 - .../video/omap2/displays/panel-toppoly-tdo35s.c| 154 +++ .../video/omap2/displays/panel-tpo-td043mtea1.c| 528 ++ drivers/video/omap2/dss/Kconfig| 26 +- drivers/video/omap2/dss/core.c | 117 ++- drivers/video/omap2/dss/dispc.c| 42 +- drivers/video/omap2/dss/display.c | 119 +-- drivers/video/omap2/dss/dpi.c | 144 +--- drivers/video/omap2/dss/dsi.c | 1031 +--- drivers/video/omap2/dss/dss.c | 42 +- drivers/video/omap2/dss/dss.h | 23 +- drivers/video/omap2/dss/manager.c | 48 +- drivers/video/omap2/dss/overlay.c |2 +- drivers/video/omap2/dss/rfbi.c | 321 +-- drivers/video/omap2/dss/sdi.c | 115 +-- drivers/video/omap2/dss/venc.c | 296 +++ drivers/video/omap2/omapfb/Kconfig | 11 +- drivers/video/omap2/omapfb/omapfb-ioctl.c | 68 +-
RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
Manju,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Manjunatha GK
Sent: Tuesday, March 02, 2010 7:36 AM
To: linux-omap@vger.kernel.org
Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja,
Govindraj
Subject: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue
The commit id 5550bc33a1a9002976022cc794fe8c52ad9a0021 seems to be
broken
zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630.
But, it looks like OMAP3630 UART4 interface and functional clock nodes
needs
to be added for omap3630. Thus limiting no. of UART's for 3630 to 3 to
prevent
boot up issues until clock nodes are added for UART4 on OMAP3630.
I already tried a similar patch here:
http://patchwork.kernel.org/patch/81692/
But as it is really not solving anything, and Tony rejected it, I started
working on the needed bits to get UART4 enabled, therefore I have came up with
this patch series:
- [RFC v3][PATCH 0/6] OMAP3630: UART4 startup (+ new bugfix!) [1]
Also, I'm working in my spare time on a cleanup proposal [2], which I'll repost
today, given some comments from Kevin.
So, if you want to boot, take series [1] and [2], and then you should be able
to boot with ttyS0.
Regards,
Sergio
---
[1] http://marc.info/?l=linux-omapm=126730356232287w=2
[2] http://marc.info/?l=linux-omapm=126746974103007w=2
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..ac22a4e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -764,7 +764,12 @@ void __init omap_serial_init(void)
{
int i, nr_ports;
- if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+ /* Limit no.of UART ports to three for OMAP3630 since
+ * clock nodes are yet to be updated for 3630 UART4.
+ * TODO: update clock nodes for 3630 UART4 and then enable
+ * check for !(cpu_is_omap3630())
+ */
+ if (!cpu_is_omap4430())
nr_ports = 3;
else
nr_ports = ARRAY_SIZE(omap_uart);
--
1.6.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
--
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/3] OMAPFB: install omapfb.h
On Mon, Mar 01, 2010 at 12:24:44PM +0100, Valkeinen Tomi (Nokia-D/Helsinki) wrote: Hi, On Tue, 2010-02-23 at 23:36 +0100, Syrjala Ville (Nokia-D/Helsinki) wrote: From: Ville Syrjälä ville.syrj...@nokia.com omapfb has several custom ioctls so user space needs the header in order to utilize them. Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com This one, and the 2/3 patch look fine, I'll apply them. The third one does not apply to my current DSS2 tree, so it needs some updating. Hmm, OK. Do you want it against master or some other branch? IIRC that's what I used. I just hit a few bugs in this patch as well so I will send a v2 soon. -- Ville Syrjälä -- 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] OMAP: Zoom3: Fix Zoom3 booting issue
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio Sent: Tuesday, March 02, 2010 10:11 AM To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Manju, snip So, if you want to boot, take series [1] and [2], and then you should be able to boot with ttyS0. Yes I could boot the zoom3 with your patchset with console on ttyS0: Relevant Boot Log: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x1000 (irq = 262) is a ST16654 console [ttyS0] enabled Regards, Sergio --- [1] http://marc.info/?l=linux-omapm=126730356232287w=2 [2] http://marc.info/?l=linux-omapm=126746974103007w=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: [PATCH 1/3] OMAPFB: install omapfb.h
On Tue, 2010-03-02 at 17:16 +0100, Syrjala Ville (Nokia-D/Helsinki) wrote: On Mon, Mar 01, 2010 at 12:24:44PM +0100, Valkeinen Tomi (Nokia-D/Helsinki) wrote: Hi, On Tue, 2010-02-23 at 23:36 +0100, Syrjala Ville (Nokia-D/Helsinki) wrote: From: Ville Syrjälä ville.syrj...@nokia.com omapfb has several custom ioctls so user space needs the header in order to utilize them. Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com This one, and the 2/3 patch look fine, I'll apply them. The third one does not apply to my current DSS2 tree, so it needs some updating. Hmm, OK. Do you want it against master or some other branch? IIRC that's what I used. I just hit a few bugs in this patch as well so I will send a v2 soon. Ok. You can use git://gitorious.org/linux-omap-dss2/linux.git for-next branch, that contains the latest official stuff. 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: [PATCHv6 1/9] OMAP3: PM: Added support functions for omap3 pwrdm handling
tero.kri...@nokia.com writes:
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 02 March, 2010 01:17
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv6 1/9] OMAP3: PM: Added support functions
for omap3 pwrdm handling
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Added omap3_pwrdm_set_next_pwrst and
omap3_pwrdm_read_next_pwrst. These
functions add support for INACTIVE and ON states to the standard OMAP
powerdomain functions, and add caching logic for the next
state. These
functions are used in subsequent patches to simplify the
logic of the idle
loop.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm34xx.c | 60
+-
2 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 75aa685..1d9a740 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -67,6 +67,8 @@ static inline void omap3_pm_init_vc(struct
prm_setup_vc *setup_vc)
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain
*pwrdm, int state);
+extern int omap3_pwrdm_set_next_pwrst(struct powerdomain
*pwrdm, u8 pwrst);
+extern int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm);
extern u32 wakeup_timer_seconds;
extern struct omap_dm_timer *gptimer_wakeup;
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 1359ec9..f20d3d8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -576,6 +576,64 @@ int omap3_can_sleep(void)
return 1;
}
+struct powerdomain_data {
+ u8 next_state;
+ u8 init_done;
+};
+
+static struct powerdomain_data mpu_pwrdm_data;
+static struct powerdomain_data core_pwrdm_data;
+static struct powerdomain_data neon_pwrdm_data;
+
+static struct powerdomain_data *get_pwrdm_data(struct
powerdomain *pwrdm)
+{
+ if (pwrdm == mpu_pwrdm)
+ return mpu_pwrdm_data;
+ else if (pwrdm == core_pwrdm)
+ return core_pwrdm_data;
+ else if (pwrdm == neon_pwrdm)
+ return neon_pwrdm_data;
+ return NULL;
+}
+
+int omap3_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
I think this func should be documented along the lines of the
changelog.
It should describe the caching and the fact that 'INACTIVE' is a state
that can be read, but not written.
Ok, will do the change.
+{
+ struct powerdomain_data *data = get_pwrdm_data(pwrdm);
+ u8 prg_pwrst;
+
+ if (!data)
+ return pwrdm_set_next_pwrst(pwrdm, pwrst);
+
+ if (!data-init_done)
+ data-init_done = 1;
Not sure I follow the purpose of the 'init_done' flag here,
but I'm having
an averse reaction to it.
init_done actually means if the cache is valid or not. If not, we ignore the
current cached state. Another way of doing this would be to initialize all
values at proper point during boot by reading from HW, or just put the HW
reset values to the cache during compile time. The cache validity bit is
needed in the read_next_pwrst code also below.
I'd rather see this done using init-time reads from the HW.
Kevin
+ else if (data-next_state == pwrst)
+ return 0;
+
+ if (pwrst == PWRDM_POWER_INACTIVE)
+ prg_pwrst = PWRDM_POWER_ON;
+ else
+ prg_pwrst = pwrst;
+
+ pwrdm_set_next_pwrst(pwrdm, prg_pwrst);
+
+ if (pwrst == PWRDM_POWER_ON)
+ omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+ else
+ omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
+
+ data-next_state = pwrst;
+ return 0;
+}
+
+int omap3_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
+{
+ struct powerdomain_data *data = get_pwrdm_data(pwrdm);
+
+ if (!data || !data-init_done)
+ return pwrdm_read_next_pwrst(pwrdm);
+ return data-next_state;
+}
+
/* This sets pwrdm state (other than mpu core. Currently only ON
* RET are supported. Function is assuming that clkdm doesn't have
* hw_sup mode enabled. */
@@ -604,7 +662,7 @@ int set_pwrdm_state(struct powerdomain
*pwrdm, u32 state)
pwrdm_wait_transition(pwrdm);
}
- ret = pwrdm_set_next_pwrst(pwrdm, state);
+ ret = omap3_pwrdm_set_next_pwrst(pwrdm, state);
if (ret) {
printk(KERN_ERR Unable to set state of
powerdomain: %s\n,
pwrdm-name);
--
1.5.4.3
--
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
Re: [PATCH v2] OMAP: DMA: Add API for setting channel dest addr
Venkatraman S svenk...@ti.com writes:
Manjunath,
On Tue, Mar 2, 2010 at 7:06 PM, Manjunatha GK manj...@ti.com wrote:
The new API - omap_set_dma_dst_pos(int lch, int value) is added
for setting channel destination address in CPC/CDAC register
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: S, Venkatraman svenk...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Signed-off-by: Govindraj R govindraj.r...@ti.com
---
arch/arm/plat-omap/dma.c | 17 +
arch/arm/plat-omap/include/plat/dma.h | 1 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2ab224c..c73f11a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1109,6 +1109,23 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
}
EXPORT_SYMBOL(omap_get_dma_dst_pos);
+/**
+ * omap_set_dma_dst_pos() - Set DMA channel destination address
+ * @arg1: lch DMA logical channel number
+ * @arg2: value Value to write into CDAC register
+ *
+ * Writes value into the register CPC/CDAC
+ */
+void omap_set_dma_dst_pos(int lch, int value)
+{
+ if (cpu_is_omap15xx())
+ dma_write(value, CPC(lch));
+ else
+ dma_write(value, CDAC(lch));
+
+}
+EXPORT_SYMBOL(omap_set_dma_dst_pos);
+
int omap_get_dma_active_status(int lch)
{
return (dma_read(CCR(lch)) OMAP_DMA_CCR_EN) != 0;
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 02232ca..3b6e43e 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -509,6 +509,7 @@ extern int omap_set_dma_callback(int lch,
void *data);
extern dma_addr_t omap_get_dma_src_pos(int lch);
extern dma_addr_t omap_get_dma_dst_pos(int lch);
+extern void omap_set_dma_dst_pos(int lch, int value);
extern void omap_clear_dma(int lch);
extern int omap_get_dma_active_status(int lch);
extern int omap_dma_running(void);
--
CDAC is not the destination address, as the API seems to suggest.
CDSA (Channel Destination Start Address) is.
CDAC is a running counter of the current transfer.
I propose to update the omap_start_dma to reset CDAC to 0 always.
I agree with Venkat. I think having it reset for every transfer
by default is the right way to handle this.
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: [PATCHv3 2/4] Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs
On Tue, Mar 2, 2010 at 12:29 PM, Anuj Aggarwal anuj.aggar...@ti.com wrote: Kconfig is modified for OMAP3 EVM so that user can choose the appropriate PMIC (currently only TWL4030). Config options for other PMICs will be added later on. Makefile is modified so that twl4030-pmic.c gets compiled for the platforms having TWL4030 as the PMIC. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Kconfig | 9 + arch/arm/mach-omap2/Makefile | 1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..1974dda 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -77,6 +77,15 @@ config MACH_OMAP3EVM depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB +config PMIC_TWL4030 + bool TWL4030/TPS65950 Power Module + default y + select TWL4030_CORE + select REGULATOR_TWL4030 if REGULATOR + help + Say yes here if you are using the TWL4030/TPS65950 based power module + for the EVM boards. + Any reason to have this user configurable? The boards that depend on it will always need it to be enabled to compile, and the ones that don't always want it disabled. config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 2069fb3..c33e24d 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -137,6 +137,7 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \ hsmmc.o +obj-$(CONFIG_PMIC_TWL4030) += twl4030-pmic.o obj-$(CONFIG_MACH_OMAP_4430SDP) += board-4430sdp.o obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o -- 1.6.2.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
[GIT PULL] omap updates for 2.6.34
Hi Linus, Please pull omap updates from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus Regards, Tony The following changes since commit ac0f6f927db539e03e1f3f61bcd4ed57d5cde7a9: Linus Torvalds (1): Merge branch 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus Abhijit Pagare (13): ARM: OMAP4: PM: OMAP4 essential basic initialisations. ARM: OMAP4: PM: OMAP4 Power Domain Porting Related Clean-up. ARM: OMAP4: PM: Add the Autogenerated OMAP4 specific power domain framework. ARM: OMAP4: PM: Adapt the existing OMAP2/3 and common Power Domain Frameworks. ARM: OMAP4: PM: Refine the APIs to support OMAP4 features. ARM: OMAP4: PM: Make OMAP3 Clock-domain framework compatible for OMAP4. ARM: OMAP4: PM: Modify Clock-domain interfaces for OMAP4 compatibility. ARM: OMAP4: PM: Add the Autogenerated OMAP4 specific clock domain framework. ARM: OMAP4: PM: Adapt the existing OMAP2/3 Clock Domain Frameworks. ARM: OMAP4: PM: Refine the APIs to support OMAP4 features. ARM: OMAP4 clock framework: Remove the checks preventing OMAP4 clockdomain validation ARM: OMAP4 clock domains : Add the missing Clock Domain Structure ARM: OMAP4 clock domain: Add check for avoiding dependency related update. Adrian Hunter (10): omap_hsmmc: Move gpio and regulator control from board file omap: Rename mmc-twl4030 files to hsmmc omap: Rename hsmmc symbols to reflect independence from twl4030 omap: Reconnect hsmmc context loss count omap: RX51: Remux to pull eMMC lines down when powering off omap_hsmmc: Allow for power saving without going off omap_hsmmc: Fix disable timeouts omap_hsmmc: Ensure regulator enable / disable are paired omap_hsmmc: Allow for a shared VccQ omap_hsmmc: allow compile without regulator framework Ajay Kumar Gupta (2): AM35x: Add missing GPIO mux config for EHCI port AM35x: Enable OMAP_MUX in defconfig Eero Nurkkala (1): McBSP: OMAP3: Add sidetone feature Enric Balletbo i Serra (8): omap3: Add platform data for the twl4030_codec MFD on IGEP v2 omap3: Fix typo on IGEP v2 board omap3: Add platform init code for EHCI driver on IGEP v2 omap3: Enable DSS2 for IGEP v2 board omap3: Add support for flash on IGEP v2 board omap3: SDRC: add timing data for Numonyx M65KAM omap3: Use timing data for omap2_init_common_hw on IGEP v2 omap3: Update defconfig for IGEP v2 to allow new drivers andfeatures Felipe Balbi (11): omap1: mailbox: kill compile warning omap2/3/4: mailbox: kill compile warning in mailbox.c omap2/3/4: gpmc: kill compile warning omap2/3/4: gpmc: avoid section definitions on headers arm: omap: kill compile warning on board-4430-sdp.c arm: omap: musb: ioremap only what's ours omap: musb: remove unused data arm: omap: musb: we can use clk framework omap: musb: remove unused soft_con field omap: musb: remove unused dma data omap: musb: remove unnecessary return Grazvydas Ignotas (3): OMAP: pandora: add DSS2 support and related regulators omap3: pandora: update regulator setup omap3: pandora: update defconfig Hiroshi DOYU (3): omap iommu: cleanup iommu page address mask and definitions omap: iommu: fix incorrect address for supersection 1st entry omap iommu: fix incorrect address for largepage 1st entry Ilkka Koskinen (1): ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone Janusz Krzysztofik (4): omap: McBSP: Use macros for all register read/write operations omap: McBSP: Modify macros/functions API for easy cache access omap: McBSP: Introduce caching in register write operations omap: McBSP: Use cache when modifying individual register bits Jarkko Nikula (1): omap: i2c: Fix muxing for command line enabled bus Jonas Zetterberg (2): IGEPv2: Added WIFI support IGEPv2: Use Red Led1 as Heartbeat if configured Jorge Eduardo Candelaria (3): OMAP4: IRQ: Add McPDM IRQ definition ARM: OMAP4: Add McPDM base address OMAP4: MCPDM: Register McPDM platform device Kalle Jokiniemi (2): OMAP3: cpuidle: Add valid field into C-state parameter passing OMAP3: RX-51: Pass cpu idle parameters Kevin Hilman (8): OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies OMAP: hwmod: add API for slave idlemode setting OMAP3: cpuidle: configure latencies/thresholds from board file OMAP3: RX-51: support sleep indicator LEDs OMAP: omap_device: add omap_device_is_valid() OMAP: omap_device: when 'called from invalid state', print state OMAP3: clock: use std _MASK suffix for CM_FCLKEN_IVA2 defines
Re: [PATCH 02/16] OMAP3: PM: Create list to keep track of various smartreflex instances.
Mike Turquette mturque...@ti.com writes:
Gopinath, Thara wrote:
This patch removes the pointer sr1, sr2 in smartreflex.c and
instead creatse a list for keeping track of multiple smartreflex
instances.. This makes it scalable for next gen OMAPs where there
are more than two smartreflex modules.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 114
1 files changed, 76 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 1c5ec37..4a9c2e2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -26,6 +26,7 @@
#include linux/kobject.h
#include linux/i2c/twl.h
#include linux/io.h
+#include linux/list.h
#include plat/omap34xx.h
#include plat/control.h
@@ -51,9 +52,12 @@ struct omap_sr {
u32 opp5_nvalue;
u32 senp_mod, senn_mod;
void __iomem*srbase_addr;
-void __iomem*vpbase_addr;
+struct list_headnode;
};
+/* sr_list contains all the instances of smartreflex module */
+static LIST_HEAD(sr_list);
+
#define SR_REGADDR(offs)(sr-srbase_addr + offset)
static inline void sr_write_reg(struct omap_sr *sr, unsigned
offset, u32 value)
@@ -78,6 +82,20 @@ static inline u32 sr_read_reg(struct omap_sr *sr,
unsigned offset)
return __raw_readl(SR_REGADDR(offset));
}
+static struct omap_sr *_sr_lookup(int srid)
+{
+struct omap_sr *sr_info, *temp_sr_info;
+
+sr_info = NULL;
+list_for_each_entry(temp_sr_info, sr_list, node) {
+if (srid == temp_sr_info-srid) {
+sr_info = temp_sr_info;
+break;
+}
+}
+return sr_info;
+}
+
static int sr_clk_enable(struct omap_sr *sr)
{
if (clk_enable(sr-clk) != 0) {
@@ -151,11 +169,17 @@ static u8 get_vdd1_opp(void)
{
struct omap_opp *opp;
unsigned long freq;
+struct omap_sr *sr_info = _sr_lookup(SR1);
Why has the list implementation been chosen over individually
registered platform devices?
Not sure I follow your question exactly here, but IIUC, Thara converts
to individually registered platform_devices in the next patch. This
is a preliminary one to prepare for that. In PATCH 03/16, the devices
are found via hwmod then registered via omap_device_build() (which in
turn does the platform_device_register())
Kevin
There seems to be a trend lately in
device drivers to have a single platform device with either an array
of pointers or a list implementation to track the multiple instances
of the same device on a board. McBSP is another example of this
approach.
Why is that? Is it a bad idea to have each SR instance be a separate
platform device? Please let me know if my question is nuts.
Mike
- if (sr1.vdd_opp_clk == NULL || IS_ERR(sr1.vdd_opp_clk))
+if (!sr_info) {
+pr_warning(omap_sr struct corresponding to SR1 not found\n);
+return 0;
+}
+
+if (sr_info-vdd_opp_clk == NULL || IS_ERR(sr_info-vdd_opp_clk))
return 0;
- freq = sr1.vdd_opp_clk-rate;
+freq = sr_info-vdd_opp_clk-rate;
opp = opp_find_freq_ceil(OPP_MPU, freq);
if (IS_ERR(opp))
return 0;
@@ -163,9 +187,9 @@ static u8 get_vdd1_opp(void)
* Use higher freq voltage even if an exact match is not available
* we are probably masking a clock framework bug, so warn
*/
-if (unlikely(freq != sr1.vdd_opp_clk-rate))
+if (unlikely(freq != sr_info-vdd_opp_clk-rate))
pr_warning(%s: Available freq %ld != dpll freq %ld.\n,
- __func__, freq, sr1.vdd_opp_clk-rate);
+ __func__, freq, sr_info-vdd_opp_clk-rate);
return opp_get_opp_id(opp);
}
@@ -174,11 +198,17 @@ static u8 get_vdd2_opp(void)
{
struct omap_opp *opp;
unsigned long freq;
+struct omap_sr *sr_info = _sr_lookup(SR2);
+
+if (!sr_info) {
+pr_warning(omap_sr struct corresponding to SR2 not found\n);
+return 0;
+}
- if (sr2.vdd_opp_clk == NULL || IS_ERR(sr2.vdd_opp_clk))
+if (sr_info-vdd_opp_clk == NULL || IS_ERR(sr_info-vdd_opp_clk))
return 0;
- freq = sr2.vdd_opp_clk-rate;
+freq = sr_info-vdd_opp_clk-rate;
opp = opp_find_freq_ceil(OPP_L3, freq);
if (IS_ERR(opp))
return 0;
@@ -187,9 +217,9 @@ static u8 get_vdd2_opp(void)
* Use higher freq voltage even if an exact match is not available
* we are probably masking a clock framework bug, so warn
*/
-if (unlikely(freq != sr2.vdd_opp_clk-rate))
+if (unlikely(freq != sr_info-vdd_opp_clk-rate))
pr_warning(%s: Available freq %ld != dpll freq %ld.\n,
- __func__, freq, sr2.vdd_opp_clk-rate);
+ __func__, freq,
Re: [PATCH 02/16] OMAP3: PM: Create list to keep track of various smartreflex instances.
ambresh a0393...@ti.com writes:
Gopinath, Thara wrote:
This patch removes the pointer sr1, sr2 in smartreflex.c and
instead creatse a list for keeping track of multiple smartreflex
instances.. This makes it scalable for next gen OMAPs where there
are more than two smartreflex modules.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 114
1 files changed, 76 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 1c5ec37..4a9c2e2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -26,6 +26,7 @@
#include linux/kobject.h
#include linux/i2c/twl.h
#include linux/io.h
+#include linux/list.h
#include plat/omap34xx.h
#include plat/control.h
@@ -51,9 +52,12 @@ struct omap_sr {
u32 opp5_nvalue;
u32 senp_mod, senn_mod;
void __iomem*srbase_addr;
-void __iomem*vpbase_addr;
+struct list_headnode;
};
+/* sr_list contains all the instances of smartreflex module */
+static LIST_HEAD(sr_list);
+
#define SR_REGADDR(offs)(sr-srbase_addr + offset)
static inline void sr_write_reg(struct omap_sr *sr, unsigned
offset, u32 value)
@@ -78,6 +82,20 @@ static inline u32 sr_read_reg(struct omap_sr *sr,
unsigned offset)
return __raw_readl(SR_REGADDR(offset));
}
+static struct omap_sr *_sr_lookup(int srid)
+{
+struct omap_sr *sr_info, *temp_sr_info;
+
+sr_info = NULL;
+list_for_each_entry(temp_sr_info, sr_list, node) {
+if (srid == temp_sr_info-srid) {
+sr_info = temp_sr_info;
+break;
+}
+}
+return sr_info;
+}
+
static int sr_clk_enable(struct omap_sr *sr)
{
if (clk_enable(sr-clk) != 0) {
@@ -151,11 +169,17 @@ static u8 get_vdd1_opp(void)
{
struct omap_opp *opp;
unsigned long freq;
+struct omap_sr *sr_info = _sr_lookup(SR1);
- if (sr1.vdd_opp_clk == NULL || IS_ERR(sr1.vdd_opp_clk))
+if (!sr_info) {
+pr_warning(omap_sr struct corresponding to SR1 not found\n);
+return 0;
+}
+
+if (sr_info-vdd_opp_clk == NULL || IS_ERR(sr_info-vdd_opp_clk))
return 0;
- freq = sr1.vdd_opp_clk-rate;
+freq = sr_info-vdd_opp_clk-rate;
opp = opp_find_freq_ceil(OPP_MPU, freq);
if (IS_ERR(opp))
return 0;
@@ -163,9 +187,9 @@ static u8 get_vdd1_opp(void)
* Use higher freq voltage even if an exact match is not available
* we are probably masking a clock framework bug, so warn
*/
-if (unlikely(freq != sr1.vdd_opp_clk-rate))
+if (unlikely(freq != sr_info-vdd_opp_clk-rate))
pr_warning(%s: Available freq %ld != dpll freq %ld.\n,
- __func__, freq, sr1.vdd_opp_clk-rate);
+ __func__, freq, sr_info-vdd_opp_clk-rate);
return opp_get_opp_id(opp);
}
@@ -174,11 +198,17 @@ static u8 get_vdd2_opp(void)
{
struct omap_opp *opp;
unsigned long freq;
+struct omap_sr *sr_info = _sr_lookup(SR2);
+
+if (!sr_info) {
+pr_warning(omap_sr struct corresponding to SR2 not found\n);
+return 0;
+}
- if (sr2.vdd_opp_clk == NULL || IS_ERR(sr2.vdd_opp_clk))
+if (sr_info-vdd_opp_clk == NULL || IS_ERR(sr_info-vdd_opp_clk))
return 0;
- freq = sr2.vdd_opp_clk-rate;
+freq = sr_info-vdd_opp_clk-rate;
opp = opp_find_freq_ceil(OPP_L3, freq);
if (IS_ERR(opp))
return 0;
@@ -187,9 +217,9 @@ static u8 get_vdd2_opp(void)
* Use higher freq voltage even if an exact match is not available
* we are probably masking a clock framework bug, so warn
*/
-if (unlikely(freq != sr2.vdd_opp_clk-rate))
+if (unlikely(freq != sr_info-vdd_opp_clk-rate))
pr_warning(%s: Available freq %ld != dpll freq %ld.\n,
- __func__, freq, sr2.vdd_opp_clk-rate);
+ __func__, freq, sr_info-vdd_opp_clk-rate);
return opp_get_opp_id(opp);
}
@@ -694,14 +724,13 @@ static void sr_disable(struct omap_sr *sr)
void sr_start_vddautocomap(int srid, u32 target_opp_no)
{
-struct omap_sr *sr = NULL;
+struct omap_sr *sr = _sr_lookup(srid);
- if (srid == SR1)
-sr = sr1;
-else if (srid == SR2)
-sr = sr2;
-else
+if (!sr) {
+pr_warning(omap_sr struct corresponding to SR%d not found\n,
+srid);
return;
+}
if (sr-is_sr_reset == 1) {
sr_clk_enable(sr);
@@ -719,14 +748,13 @@ EXPORT_SYMBOL(sr_start_vddautocomap);
int sr_stop_vddautocomap(int srid)
{
-struct omap_sr *sr = NULL;
+struct omap_sr *sr = _sr_lookup(srid);
- if (srid == SR1)
-
[PATCH v2] DSS2: OMAPFB: Add support for switching memory regions
From: Ville Syrjälä ville.syrj...@nokia.com
Separate the memory region from the framebuffer device a little bit.
It's now possible to select the memory region used by the framebuffer
device using the new source_idx parameter of omapfb_plane_info. If the
source_idx is specified it will be interpreted as an index into the
memory regions array, if it's not specified the framebuffer's index is
used instead. So by default each framebuffer keeps using it's own
memory region which preserves backwards compatibility.
This allows cloning the same memory region to several overlays and yet
each overlay can be controlled independently since they can be
associated with separate framebuffer devices.
Signed-off-by: Ville Syrjälä ville.syrj...@nokia.com
---
Changes since v1:
* Fixed an array bounds check in get_mem_region()
* Fixed a locking issue in omapfb_setup_plane() error path
drivers/video/omap2/omapfb/omapfb-ioctl.c | 157 +++-
drivers/video/omap2/omapfb/omapfb-main.c | 185 +++--
drivers/video/omap2/omapfb/omapfb-sysfs.c | 47 +--
drivers/video/omap2/omapfb/omapfb.h | 47 +++-
include/linux/omapfb.h|5 +-
5 files changed, 327 insertions(+), 114 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 4c4bafd..7141bc9 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -34,12 +34,37 @@
#include omapfb.h
+static u8 get_source_idx(struct omapfb_info *ofbi)
+{
+ if (ofbi-id == ofbi-region-id)
+ return 0;
+
+ return OMAPFB_SOURCE_IDX_ENABLED | ofbi-region-id;
+}
+
+static struct omapfb2_mem_region *get_mem_region(struct omapfb_info *ofbi,
+u8 source_idx)
+{
+ struct omapfb2_device *fbdev = ofbi-fbdev;
+
+ if (source_idx OMAPFB_SOURCE_IDX_ENABLED)
+ source_idx = OMAPFB_SOURCE_IDX_MASK;
+ else
+ source_idx = ofbi-id;
+
+ if (source_idx = fbdev-num_fbs)
+ return NULL;
+
+ return omapfb_get_mem_region(fbdev-regions[source_idx]);
+}
+
static int omapfb_setup_plane(struct fb_info *fbi, struct omapfb_plane_info
*pi)
{
struct omapfb_info *ofbi = FB2OFB(fbi);
struct omapfb2_device *fbdev = ofbi-fbdev;
struct omap_overlay *ovl;
- struct omap_overlay_info info;
+ struct omap_overlay_info old_info;
+ struct omapfb2_mem_region *old_rg, *new_rg;
int r = 0;
DBG(omapfb_setup_plane\n);
@@ -52,57 +77,111 @@ static int omapfb_setup_plane(struct fb_info *fbi, struct
omapfb_plane_info *pi)
/* XXX uses only the first overlay */
ovl = ofbi-overlays[0];
- if (pi-enabled !ofbi-region.size) {
+ old_rg = omapfb_get_mem_region(ofbi-region);
+ new_rg = get_mem_region(ofbi, pi-source_idx);
+ if (!new_rg) {
+ r = -EINVAL;
+ goto put_old;
+ }
+
+ if (pi-enabled !new_rg-size) {
/*
* This plane's memory was freed, can't enable it
* until it's reallocated.
*/
r = -EINVAL;
- goto out;
+ goto put_new;
}
- ovl-get_overlay_info(ovl, info);
+ ovl-get_overlay_info(ovl, old_info);
- info.pos_x = pi-pos_x;
- info.pos_y = pi-pos_y;
- info.out_width = pi-out_width;
- info.out_height = pi-out_height;
- info.enabled = pi-enabled;
+ if (old_rg != new_rg) {
+ ofbi-region = new_rg;
+ set_fb_fix(fbi);
+ }
- r = ovl-set_overlay_info(ovl, info);
- if (r)
- goto out;
+ if (pi-enabled) {
+ struct omap_overlay_info info;
- if (ovl-manager) {
- r = ovl-manager-apply(ovl-manager);
+ r = omapfb_setup_overlay(fbi, ovl, pi-pos_x, pi-pos_y,
+ pi-out_width, pi-out_height);
if (r)
- goto out;
+ goto undo;
+
+ ovl-get_overlay_info(ovl, info);
+
+ if (!info.enabled) {
+ info.enabled = pi-enabled;
+ r = ovl-set_overlay_info(ovl, info);
+ if (r)
+ goto undo;
+ atomic_inc(new_rg-use_count);
+ } else {
+ atomic_inc(new_rg-use_count);
+ atomic_dec(old_rg-use_count);
+ }
+ } else {
+ struct omap_overlay_info info;
+ bool enabled;
+
+ ovl-get_overlay_info(ovl, info);
+
+ enabled = info.enabled;
+
+ info.enabled = pi-enabled;
+ info.pos_x = pi-pos_x;
+ info.pos_y = pi-pos_y;
+ info.out_width =
Re: [PATCH 06/16] OMAP3: PM: Smartreflex class related changes for smartreflex.c
Thara Gopinath th...@ti.com writes:
OMAP3 smartreflex modules are capable of two different classes
of implementaion -
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration.
OMAP3 along with T2/Gaia supports the Class 3 implementaion.
With a different PMIC it can support Class 2 implementaion also.
The idea behind this patch is that smartreflex.c should be able
to support both the classes of Smartreflex and the class specific
details for smartreflex should stay out of this file in a separate
class file.
This patch introduces smartreflex class specific hooks in
smartreflex.c. This patch only takes care of smartreflex enable
disable hooks which differ between Class 2 and Class 3. There
are some register setting changes between both the classes which
will be taken care of in a later patch.
This will form the base for adding class specific
drivers in later patches.
Signed-off-by: Thara Gopinath th...@ti.com
Minor nit: the name change for omap_smartreflex_[enable|disable] is
unrelated to this change and should be a separate patch to go early in
the series.
Kevin
---
arch/arm/mach-omap2/pm34xx.c |8 +-
arch/arm/mach-omap2/smartreflex.c | 251
arch/arm/mach-omap2/smartreflex.h | 48 ++--
3 files changed, 182 insertions(+), 125 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index cf9ca23..ece5195 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -430,9 +430,9 @@ void omap_sram_idle(void)
* Only needed if we are going to enter retention or off.
*/
if (mpu_next_state = PWRDM_POWER_RET)
- disable_smartreflex(SR1);
+ omap_smartreflex_disable(SR1);
if (core_next_state = PWRDM_POWER_RET)
- disable_smartreflex(SR2);
+ omap_smartreflex_disable(SR2);
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
@@ -531,9 +531,9 @@ void omap_sram_idle(void)
* retention or off
*/
if (mpu_next_state = PWRDM_POWER_RET)
- enable_smartreflex(SR1);
+ omap_smartreflex_enable(SR1);
if (core_next_state = PWRDM_POWER_RET)
- enable_smartreflex(SR2);
+ omap_smartreflex_enable(SR2);
/* PER */
if (per_next_state PWRDM_POWER_ON) {
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c00925d..ba9f899 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -55,6 +55,7 @@ struct omap_sr {
/* sr_list contains all the instances of smartreflex module */
static LIST_HEAD(sr_list);
+static struct omap_smartreflex_class_data *sr_class;
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
@@ -388,14 +389,86 @@ static int sr_reset_voltage(int srid)
return 0;
}
-static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
+static void sr_start_vddautocomap(int srid)
+{
+ struct omap_sr *sr = _sr_lookup(srid);
+
+ if (!sr) {
+ pr_warning(omap_sr struct corresponding to SR%d not found\n,
+ srid);
+ return;
+ }
+
+ if (!sr_class || !(sr_class-enable)) {
+ pr_warning(smartreflex class driver not registered\n);
+ return;
+ }
+
+ if (sr-is_sr_reset == 1) {
+ sr_clk_enable(sr);
+ sr_configure(sr);
+ }
+
+ sr-is_autocomp_active = 1;
+ if (!sr_class-enable(srid)) {
+ sr-is_autocomp_active = 0;
+ if (sr-is_sr_reset == 1)
+ sr_clk_disable(sr);
+ }
+}
+
+static void sr_stop_vddautocomap(int srid)
+{
+ struct omap_sr *sr = _sr_lookup(srid);
+
+ if (!sr) {
+ pr_warning(omap_sr struct corresponding to SR%d not found\n,
+ srid);
+ return;
+ }
+ if (!sr_class || !(sr_class-disable)) {
+ pr_warning(smartreflex class driver not registered\n);
+ return;
+ }
+
+ if (sr-is_autocomp_active == 1) {
+ sr_class-disable(srid);
+ sr_clk_disable(sr);
+ sr-is_autocomp_active = 0;
+ /* Reset the volatage for current OPP */
+ sr_reset_voltage(srid);
+ }
+
+}
+
+/* Public Functions */
+
+/**
+ * sr_enable : Enables the smartreflex module.
+ * @srid - The id of the sr module to be enabled.
+ * @target_opp_no - The OPP at which the Voltage domain associated with
+ * the smartreflex module is operating at. This is required only to program
+ * the correct Ntarget value.
+ *
+ * This API is to be called from the smartreflex class driver to
+ * enable a smartreflex module. Returns true on success.Returns false if the
+ * target opp id
Re: [PATCH 03/16] OMAP3: PM: Convert smartreflex driver into a platform driver using hwmods and omap-device layer
Thara Gopinath th...@ti.com writes:
This patch converts the exisitng smartreflex library into a
platform driver with device , driver registrations using hardware mods.
As part of this Ntarget values are passed as platform data.
Signed-off-by: Thara Gopinath th...@ti.com
Nice work Thara. This is good. Some minor comments below, but some
general comments first.
As discussed, eventually (longer term) we'll want to move the driver
parts of this to a regulator driver. To ease that transition, I think
it would be nice to start now by separating the driver portions of
this file from the device portions.
You've already done a good job of keeping them separate in this file
(most of the device stuff is at the end) but I think having a separate
file is probably even better. Maybe move driver stuff to sr_driver.c
and leave device stuff in smartreflex.c? I don't care much about the
names at this point.
---
arch/arm/mach-omap2/smartreflex.c | 470
+
arch/arm/mach-omap2/smartreflex.h | 27 ++
2 files changed, 293 insertions(+), 204 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 4a9c2e2..05c72b2 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -14,7 +14,6 @@
* published by the Free Software Foundation.
*/
-
#include linux/kernel.h
#include linux/init.h
#include linux/interrupt.h
@@ -33,6 +32,8 @@
#include plat/clock.h
#include plat/opp.h
#include plat/opp_twl_tps.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include prm.h
#include smartreflex.h
@@ -41,17 +42,14 @@
#define MAX_TRIES 100
struct omap_sr {
- int srid;
- int is_sr_reset;
- int is_autocomp_active;
- struct clk *clk;
- struct clk *vdd_opp_clk;
- u32 clk_length;
- u32 req_opp_no;
- u32 opp1_nvalue, opp2_nvalue, opp3_nvalue, opp4_nvalue;
- u32 opp5_nvalue;
- u32 senp_mod, senn_mod;
- void __iomem*srbase_addr;
+ int srid;
+ int is_sr_reset;
+ int is_autocomp_active;
+ struct clk *vdd_opp_clk;
+ u32 clk_length;
+ void __iomem*srbase_addr;
+ unsigned intirq;
+ struct platform_device *pdev;
struct list_headnode;
};
@@ -98,71 +96,22 @@ static struct omap_sr *_sr_lookup(int srid)
static int sr_clk_enable(struct omap_sr *sr)
{
- if (clk_enable(sr-clk) != 0) {
- pr_err(Could not enable %s\n, sr-clk-name);
- return -1;
- }
+ struct omap_smartreflex_data *pdata = sr-pdev-dev.platform_data;
- /* set fclk- active , iclk- idle */
- sr_modify_reg(sr, ERRCONFIG, SR_CLKACTIVITY_MASK,
- SR_CLKACTIVITY_IOFF_FON);
+ if (pdata-device_enable)
+ pdata-device_enable(sr-pdev);
return 0;
}
static void sr_clk_disable(struct omap_sr *sr)
{
- /* set fclk, iclk- idle */
- sr_modify_reg(sr, ERRCONFIG, SR_CLKACTIVITY_MASK,
- SR_CLKACTIVITY_IOFF_FOFF);
-
- clk_disable(sr-clk);
- sr-is_sr_reset = 1;
-}
+ struct omap_smartreflex_data *pdata = sr-pdev-dev.platform_data;
-static struct omap_sr sr1 = {
- .srid = SR1,
- .is_sr_reset= 1,
- .is_autocomp_active = 0,
- .clk_length = 0,
- .srbase_addr= OMAP2_L4_IO_ADDRESS(OMAP34XX_SR1_BASE),
-};
-
-static struct omap_sr sr2 = {
- .srid = SR2,
- .is_sr_reset= 1,
- .is_autocomp_active = 0,
- .clk_length = 0,
- .srbase_addr= OMAP2_L4_IO_ADDRESS(OMAP34XX_SR2_BASE),
-};
+ if (pdata-device_idle)
+ pdata-device_idle(sr-pdev);
-static void cal_reciprocal(u32 sensor, u32 *sengain, u32 *rnsen)
-{
- u32 gn, rn, mul;
-
- for (gn = 0; gn GAIN_MAXLIMIT; gn++) {
- mul = 1 (gn + 8);
- rn = mul / sensor;
- if (rn R_MAXLIMIT) {
- *sengain = gn;
- *rnsen = rn;
- }
- }
-}
-
-static u32 cal_test_nvalue(u32 sennval, u32 senpval)
-{
- u32 senpgain, senngain;
- u32 rnsenp, rnsenn;
-
- /* Calculating the gain and reciprocal of the SenN and SenP values */
- cal_reciprocal(senpval, senpgain, rnsenp);
- cal_reciprocal(sennval, senngain, rnsenn);
-
- return (senpgain NVALUERECIPROCAL_SENPGAIN_SHIFT) |
- (senngain NVALUERECIPROCAL_SENNGAIN_SHIFT) |
- (rnsenp NVALUERECIPROCAL_RNSENP_SHIFT) |
- (rnsenn NVALUERECIPROCAL_RNSENN_SHIFT);
+ sr-is_sr_reset = 1;
}
static u8
Re: [PATCH 04/16] OMAP3: PM: Move smartreflex autocompensation enable disable hooks to PM debugfs.
Thara Gopinath th...@ti.com writes:
This patch moves the hooks to enable disable smartreflex
autocompensation to pm debugfs from the /sys/power/.
To enable autocompensation for smartreflex SRn do
echo 1 path/pm_debug/srn_autocomp
To disable autocompensation for smartreflex SRn do
echo 0 path/pm_debug/srn_autocomp
Signed-off-by: Thara Gopinath th...@ti.com
Looks good.
Kevin
---
arch/arm/mach-omap2/pm-debug.c|4 +-
arch/arm/mach-omap2/smartreflex.c | 114 ++--
arch/arm/mach-omap2/smartreflex.h |2 +
3 files changed, 36 insertions(+), 84 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index ec76f3b..7931bad 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -162,7 +162,7 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
static void pm_dbg_regset_store(u32 *ptr);
-struct dentry *pm_dbg_dir;
+struct dentry *pm_dbg_dir, *pm_dbg_main_dir;
static int pm_dbg_init_done;
@@ -608,7 +608,7 @@ static int __init pm_dbg_init(void)
S_IRUGO | S_IWUGO, d,
voltage_off_while_idle,
pm_dbg_option_fops);
-
+ pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
return 0;
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 05c72b2..db2e9bf 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -21,11 +21,11 @@
#include linux/delay.h
#include linux/err.h
#include linux/clk.h
-#include linux/sysfs.h
#include linux/kobject.h
#include linux/i2c/twl.h
#include linux/io.h
#include linux/list.h
+#include linux/debugfs.h
#include plat/omap34xx.h
#include plat/control.h
@@ -40,6 +40,7 @@
#include prm-regbits-34xx.h
#define MAX_TRIES 100
+#define SMARTREFLEX_NAME_LEN 16
struct omap_sr {
int srid;
@@ -797,103 +798,53 @@ int sr_voltagescale_vcbypass(u32 target_opp, u32
current_opp,
return 0;
}
-/* Sysfs interface to select SR VDD1 auto compensation */
-static ssize_t omap_sr_vdd1_autocomp_show(struct kobject *kobj,
- struct kobj_attribute *attr, char *buf)
+/* PM Debug Fs enteries to enable disable smartreflex.*/
+
+static int omap_sr_autocomp_show(void *data, u64 *val)
{
- struct omap_sr *sr_info = _sr_lookup(SR1);
+ struct omap_sr *sr_info = (struct omap_sr *) data;
if (!sr_info) {
- pr_warning(omap_sr struct corresponding to SR1 not found\n);
+ pr_warning(omap_sr struct corresponding to SR%d not found\n,
+ sr_info-srid);
return 0;
}
- return sprintf(buf, %d\n, sr_info-is_autocomp_active);
-}
-
-static ssize_t omap_sr_vdd1_autocomp_store(struct kobject *kobj,
- struct kobj_attribute *attr,
- const char *buf, size_t n)
-{
- unsigned short value;
-
- if (sscanf(buf, %hu, value) != 1 || (value 1)) {
- pr_err(sr_vdd1_autocomp: Invalid value\n);
- return -EINVAL;
- }
-
- if (value == 0) {
- sr_stop_vddautocomap(SR1);
- } else {
- u32 current_vdd1opp_no = get_vdd1_opp();
- if (!current_vdd1opp_no) {
- pr_err(sr_vdd1_autocomp: Current VDD1 opp unknown\n);
- return -EINVAL;
- }
- sr_start_vddautocomap(SR1, current_vdd1opp_no);
- }
- return n;
+ *val = sr_info-is_autocomp_active;
+ return 0;
}
-static struct kobj_attribute sr_vdd1_autocomp = {
- .attr = {
- .name = __stringify(sr_vdd1_autocomp),
- .mode = 0644,
- },
- .show = omap_sr_vdd1_autocomp_show,
- .store = omap_sr_vdd1_autocomp_store,
-};
-
-/* Sysfs interface to select SR VDD2 auto compensation */
-static ssize_t omap_sr_vdd2_autocomp_show(struct kobject *kobj,
- struct kobj_attribute *attr, char *buf)
+static int omap_sr_autocomp_store(void *data, u64 val)
{
- struct omap_sr *sr_info = _sr_lookup(SR2);
+ struct omap_sr *sr_info = (struct omap_sr *) data;
if (!sr_info) {
- pr_warning(omap_sr struct corresponding to SR2 not found\n);
+ pr_warning(omap_sr struct corresponding to SR%d not found\n,
+ sr_info-srid);
return 0;
}
- return sprintf(buf, %d\n, sr_info-is_autocomp_active);
-}
-
-static ssize_t omap_sr_vdd2_autocomp_store(struct kobject *kobj,
- struct kobj_attribute *attr,
- const char *buf, size_t n)
-{
Re: [PATCH 07/16] OMAP3: PM: Adding smartreflex class 3 driver.
Thara Gopinath th...@ti.com writes:
This patch adds smartreflex class 3 driver. This driver hooks
up with the generic smartreflex driver smartreflex.c to abstract
out class specific implementations out of the generic driver.
Signed-off-by: Thara Gopinath th...@ti.com
I like this abstraction, but I don't like that it still uses OPP IDs.
So, before doing this, we need to get rid of OPP IDs from the
smartreflex layer and keep OPP ID usage isolated to SRF.
It appears the only reason we need OPP IDs in SR is because the Nvalue
tables are indexed by OPP ID in sr_enable().
One way to fix this is for this SR layer to keep it's own mapping of
voltage to nvalue. So instead of taking OPP ID, sr_enable() should
take a voltage (or frequency) and use that to look up the nvalue.
a couple other minor comments below...
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex-class3.c | 49
++
arch/arm/plat-omap/Kconfig | 11 ++-
3 files changed, 60 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex-class3.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f6f901f..cd8ab86 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
+obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
new file mode 100644
index 000..d2e98a5
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -0,0 +1,49 @@
+/*
+ * Smart reflex Class 3 specific implementations
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
2010
+ * Thara Gopinath th...@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 smartreflex.h
+
+static int sr_class3_enable(int id)
+{
+ int target_opp_no = 0;
insert blank line
+ if (id == SR1)
+ target_opp_no = get_vdd1_opp();
+ else if (id == SR2)
+ target_opp_no = get_vdd2_opp();
+ if (!target_opp_no) {
+ pr_warning(Targetopp not known.Cannot enable SR%d\n, id);
+ return false;
+ }
and here
+ return sr_enable(id, target_opp_no);
+}
+static int sr_class3_disable(int id)
+{
+ int target_opp_no = 0;
blank line
+ if (id == SR1)
+ target_opp_no = get_vdd1_opp();
+ else if (id == SR2)
+ target_opp_no = get_vdd2_opp();
+ sr_disable(id);
blank line
+ return true;
+}
+/* SR class3 structure */
+struct omap_smartreflex_class_data class3_data = {
+ .enable = sr_class3_enable,
+ .disable = sr_class3_disable,
+};
+
+static int __init sr_class3_init(void)
+{
+ omap_sr_register_class(class3_data);
+ return 0;
+}
+late_initcall(sr_class3_init);
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index cef67f3..9d286e6 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -54,7 +54,7 @@ config OMAP_DEBUG_LEDS
config OMAP_SMARTREFLEX
bool SmartReflex support
- depends on ARCH_OMAP3 TWL4030_CORE PM
+ depends on ARCH_OMAP3 PM
help
Say Y if you want to enable SmartReflex.
@@ -69,6 +69,15 @@ config OMAP_SMARTREFLEX
compensation for VDD1 and VDD2, user must write 1 to
/sys/power/sr_vddX_autocomp, where X is 1 or 2.
+config OMAP_SMARTREFLEX_CLASS3
+ bool Class 3 mode of Smartreflex Implementation
+ depends on OMAP_SMARTREFLEX TWL4030_CORE
+ help
+ Say Y to enable Class 3 implementation of Smartreflex
+
+ Class 3 implementation of Smartreflex employs continuous hardware
+ voltage caliberation.
+
config OMAP_SMARTREFLEX_TESTING
bool Smartreflex testing support
depends on OMAP_SMARTREFLEX
--
1.7.0.rc1.33.g07cf0f
--
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/16] OMAP3: PM: Creating separate files for handling OMAP3 voltage related operations.
Thara Gopinath th...@ti.com writes:
This patch creates voltage.c and voltage.h files and
moves all voltage processor and voltage controller specific code
from smartreflex.c and other places in the OMAP3 codebase into
these two files.
This along with smartreflex class driver addition will make
smartreflex.c a generic driver to support both Class 2 and
Class 3 smartreflex implementaions.
Signed-off-by: Thara Gopinath th...@ti.com
This is definitely in the right direction. Thanks Thara.
Also, is this expected to be common for OMAP4? If not, maybe
this should be named voltage3xxx.[ch]?
More comments below, primarily regarding how the various VP/VC
registers are defined and accessed. I'd rather see them as offsets
into the PRCM rather than absolute virtual addresses. More on that
below...
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/board-3430sdp.c |3 +-
arch/arm/mach-omap2/pm.h |7 -
arch/arm/mach-omap2/pm34xx.c | 87 +-
arch/arm/mach-omap2/resource34xx.c | 15 +-
arch/arm/mach-omap2/resource34xx.h |1 -
arch/arm/mach-omap2/smartreflex-class3.c |4 +
arch/arm/mach-omap2/smartreflex.c| 370 +
arch/arm/mach-omap2/smartreflex.h| 139
arch/arm/mach-omap2/voltage.c| 550
++
arch/arm/mach-omap2/voltage.h| 74
11 files changed, 640 insertions(+), 613 deletions(-)
create mode 100644 arch/arm/mach-omap2/voltage.c
create mode 100644 arch/arm/mach-omap2/voltage.h
[...]
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
new file mode 100644
index 000..c0c2c17
--- /dev/null
+++ b/arch/arm/mach-omap2/voltage.c
@@ -0,0 +1,550 @@
+/*
+ * OMAP3/OMAP4 Voltage Management Routines
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ * Lesly A M x0080...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@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/pm.h
+#include linux/delay.h
+#include linux/io.h
+
+#include plat/omap-pm.h
+#include plat/omap34xx.h
+#include plat/opp.h
+#include plat/opp_twl_tps.h
+
+#include prm-regbits-34xx.h
+#include voltage.h
+
+#define MAX_TRIES 100
+
+/**
+ * OMAP3 Voltage controller SR parameters. TODO: Pass this info as part of
+ * board data or PMIC data
+ */
+#define R_SRI2C_SLAVE_ADDR 0x12
+#define R_VDD1_SR_CONTROL 0x00
+#define R_VDD2_SR_CONTROL0x01
+
+
+/* Voltage processor register offsets */
+struct vp_reg_offs {
+ void __iomem *vp_vpconfig_reg;
+ void __iomem *vp_vstepmin_reg;
+ void __iomem *vp_vstepmax_reg;
+ void __iomem *vp_vlimitto_reg;
+ void __iomem *vp_status_reg;
+ void __iomem *vp_voltage_reg;
+};
+/*
+ * Voltage processor structure conttaining info about
+ * the various register offsets and the bit field values
+ * for a particular instance of voltage processor.
+ */
+struct vp_reg_info {
+ struct vp_reg_offs vp_offs;
+ /* Bit fields for VPx_VPCONFIG */
+ u32 vp_erroroffset;
+ u32 vp_errorgain;
+ /* Bit fields for VPx_VSTEPMIN */
+ u32 vp_stepmin;
+ u32 vp_smpswaittimemin;
+ /* Bit fields for VPx_VSTEPMAX */
+ u32 vp_stepmax;
+ u32 vp_smpswaittimemax;
+ /* Bit fields for VPx_VLIMITTO */
+ u32 vp_vddmin;
+ u32 vp_vddmax;
+ u32 vp_timeout;
+};
+static struct vp_reg_info *vp_reg;
+/*
+ * Number of scalable voltage domains that has an independent
+ * Voltage processor
+ */
+static int no_scalable_vdd;
+
+/* OMAP3 VP register offsets and other definitions */
+struct __init vp_reg_offs omap3_vp_offs[] = {
+ /* VP1 */
+ {
+ .vp_vpconfig_reg = OMAP3430_PRM_VP1_CONFIG,
+ .vp_vstepmin_reg = OMAP3430_PRM_VP1_VSTEPMIN,
+ .vp_vstepmax_reg = OMAP3430_PRM_VP1_VSTEPMAX,
+ .vp_vlimitto_reg = OMAP3430_PRM_VP1_VLIMITTO,
+ .vp_status_reg = OMAP3430_PRM_VP1_STATUS,
+ .vp_voltage_reg = OMAP3430_PRM_VP1_VOLTAGE,
+ },
+ /* VP2 */
+ { .vp_vpconfig_reg = OMAP3430_PRM_VP2_CONFIG,
+ .vp_vstepmin_reg = OMAP3430_PRM_VP2_VSTEPMIN,
+ .vp_vstepmax_reg = OMAP3430_PRM_VP2_VSTEPMAX,
+ .vp_vlimitto_reg = OMAP3430_PRM_VP2_VLIMITTO,
+ .vp_status_reg = OMAP3430_PRM_VP2_STATUS,
+ .vp_voltage_reg = OMAP3430_PRM_VP2_VOLTAGE,
+ },
+};
+
Rather than absolute physical addresses, these should all simply be u8
offset values from the GR_MOD base. Changing the type to u8
and
omap code merged to mainline, fixes only for -rc, no more -omap releases
Hi all, Linus just pulled our code for 2.6.34, so let's now concentrate on the fixes for for 2.6.34 -rc cycle. So no more new code please except for the 2.6.35 merge window. It seems like we can send about 1/3 of all the patches during the -rc cycle as fixes, so please tweak the patches accordingly if you want them in during the -rc cycle. For the fixes, please specify what it fixes in the patch description. And please have the magic word fix somewhere in the patch subject too. For the patches going into 2.6.35 merge window, we need to have those tested and integrated in linux-omap master branch by 2.6.34-rc6 or so. I'll be rebuilding linux-omap master branch again today on top of the current code from Linus. I will not tag 2.6.33-omap1 or anything like that as 2.6.33 _mainline_ tree is our stable tree. So please base any products and distros on the _mainline_ recent stable version, currently 2.6.33, and apply the patches you need on top of it. I guess that's mostly Kevin's PM branch and Tomi's DSS2 branch that you might want to apply. This way we are following the standard Linux development cycle. Also, I'll be taking few days off starting Wednesday :) Regards, 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 v2] board-n8x0: add USB initialization
* Francisco Alecrim alec...@gmail.com [100301 14:12]:
From: Francisco Alecrim francisco.alec...@openbossa.org
Based on Kalle's and Tony's patches. Some variables re-organized and
unused code remove(68499cc5716bbeca16ca8c83ec6e9f04b8dbfacb).
Looks like this needs to be refreshed against what's now in mainline.
Tony
Signed-off-by: Kalle Valo kalle.v...@iki.fi
Signed-off-by: Francisco Alecrim francisco.alec...@openbossa.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-n8x0.c | 92
++
arch/arm/mach-omap2/clock2420_data.c |1 +
include/linux/usb/musb.h |4 ++
3 files changed, 97 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c
b/arch/arm/mach-omap2/board-n8x0.c
index ee548dd..79d659a 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -32,6 +32,97 @@
#include plat/serial.h
#include plat/cbus.h
+#if defined(CONFIG_USB_TUSB6010) || \
+ defined(CONFIG_USB_TUSB6010_MODULE)
+/*
+ * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
+ * 1.5 V voltage regulators of PM companion chip. Companion chip will then
+ * provide then PGOOD signal to TUSB6010 which will release it from reset.
+ */
+static int tusb_set_power(int state)
+{
+ int i, retval = 0;
+
+ if (state) {
+ gpio_set_value(TUSB6010_GPIO_ENABLE, 1);
+ msleep(1);
+
+ /* Wait until TUSB6010 pulls INT pin down */
+ i = 100;
+ while (i gpio_get_value(TUSB6010_GPIO_INT)) {
+ msleep(1);
+ i--;
+ }
+
+ if (!i) {
+ printk(KERN_ERR tusb: powerup failed\n);
+ retval = -ENODEV;
+ }
+ } else {
+ gpio_set_value(TUSB6010_GPIO_ENABLE, 0);
+ msleep(10);
+ }
+
+ return retval;
+}
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .num_eps= 16,
+ .ram_bits = 12,
+};
+
+static struct musb_hdrc_platform_data tusb_data = {
+#if defined(CONFIG_USB_MUSB_OTG)
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
+ .mode = MUSB_PERIPHERAL,
+#else /* defined(CONFIG_USB_MUSB_HOST) */
+ .mode = MUSB_HOST,
+#endif
+ .set_power = tusb_set_power,
+ .min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
+ .power = 100, /* Max 100 mA VBUS for host mode */
+ .config = musb_config,
+};
+
+static void __init n8x0_usb_init(void)
+{
+ int ret = 0;
+ static char announce[] __initdata = KERN_INFO TUSB 6010\n;
+
+ /* PM companion chip power control pin */
+ ret = gpio_request(TUSB6010_GPIO_ENABLE, TUSB6010 enable);
+ if (ret != 0) {
+ printk(KERN_ERR Could not get TUSB power GPIO%i\n,
+TUSB6010_GPIO_ENABLE);
+ return;
+ }
+ gpio_direction_output(TUSB6010_GPIO_ENABLE, 0);
+
+ tusb_set_power(0);
+
+ ret = tusb6010_setup_interface(tusb_data, TUSB6010_REFCLK_19, 2,
+ TUSB6010_ASYNC_CS, TUSB6010_SYNC_CS,
+ TUSB6010_GPIO_INT, 0x3f);
+ if (ret != 0)
+ goto err;
+
+ printk(announce);
+
+ return;
+
+err:
+ gpio_free(TUSB6010_GPIO_ENABLE);
+}
+#else
+
+static void __init n8x0_usb_init(void) {}
+
+#endif /*CONFIG_USB_TUSB6010 */
+
+
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -148,6 +239,7 @@ static void __init n8x0_init_machine(void)
omap_serial_init();
n8x0_onenand_init();
+ n8x0_usb_init();
}
MACHINE_START(NOKIA_N800, Nokia N800)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index f12af95..d932b14 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1841,6 +1841,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, aes_ick, aes_ick, CK_242X),
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
+ CLK(musb_hdrc,fck, osc_ck,CK_242X),
};
/*
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 3fdeef5..c281ce0 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -98,6 +98,10 @@ struct musb_hdrc_platform_data {
#define TUSB6010_OSCCLK_60 16667 /* psec/clk @ 60.0 MHz */
#define TUSB6010_REFCLK_24 41667 /* psec/clk @ 24.0 MHz XI */
#define TUSB6010_REFCLK_19 52083 /* psec/clk @ 19.2 MHz CLKIN */
+#define TUSB6010_ASYNC_CS1
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Thursday, February 18, 2010 4:16 PM To: Paul Walmsley Cc: Madhusudhan; David Vrabel; r-woodru...@ti.com; saw...@ti.com; linux- m...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts On Thu, Feb 18, 2010 at 12:21 PM, Paul Walmsley p...@pwsan.com wrote: (cc'ing Steve, Richard, Anand) There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least one of these is for a TI chip - the wl1251. I think some of the Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: http://www.gumstix.com/store/catalog/product_info.php?products_id=252 That is correct, a Wi2Wi wifi module is connected via mmc2 on the Overo Air and Fire products. Steve, A dumb question. Is this Wi2Wi wifi module available as a standard SDIO card which can be plugged into a SD card cage? Or is it specifically designed for the gumstix board? Regards, Madhu Data rates are pretty low with the existing OMAP SDIO driver. Any chance this patch would improve that situation? Just added applying the patch and retesting data rates to my to do list :-) Steve David is probably testing with a Bluetooth card - maybe he can comment further. And at least I don't see a way I can test any of these features myself. Could you clarify? - 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] omap: i2c: Add i2c support on omap4 platform
* Shilimkar, Santosh santosh.shilim...@ti.com [100227 21:28]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Sunday, February 28, 2010 2:11 AM To: Shilimkar, Santosh Cc: ben-li...@fluff.org; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Syed, Rafiuddin; Cory Maccarrone; a...@linux-foundation.org Subject: Re: [PATCH] omap: i2c: Add i2c support on omap4 platform * Shilimkar, Santosh santosh.shilim...@ti.com [100226 20:05]: Tony, What we do with patch now? It's more almost 6 months that this patch is floating without merge. Well first we should test it for all omaps. So let's add it into omap-testing for a few days to make sure it does not break anything. Then let's ask Ben to queue it. Ok with me. I've tried it out and seems to work just fine on 2420. I've applied it for testing into omap-testing (and master) branches now. Would be nice to get an ack from people using 7xx too on this. 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: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
On Tue, Mar 2, 2010 at 2:08 PM, Madhusudhan madhu...@ti.com wrote: That is correct, a Wi2Wi wifi module is connected via mmc2 on the Overo Air and Fire products. A dumb question. Is this Wi2Wi wifi module available as a standard SDIO card which can be plugged into a SD card cage? Or is it specifically designed for the gumstix board? The module on Overo is soldered directly to the board. It is a standard part, not custom. I am not aware if wi2wi also sells a SD version. Steve -- 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 06/16] OMAP3: PM: Smartreflex class related changes for smartreflex.c
Thara Gopinath th...@ti.com writes:
OMAP3 smartreflex modules are capable of two different classes
of implementaion -
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration.
OMAP3 along with T2/Gaia supports the Class 3 implementaion.
With a different PMIC it can support Class 2 implementaion also.
The idea behind this patch is that smartreflex.c should be able
to support both the classes of Smartreflex and the class specific
details for smartreflex should stay out of this file in a separate
class file.
This patch introduces smartreflex class specific hooks in
smartreflex.c. This patch only takes care of smartreflex enable
disable hooks which differ between Class 2 and Class 3. There
are some register setting changes between both the classes which
will be taken care of in a later patch.
This will form the base for adding class specific
drivers in later patches.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |8 +-
arch/arm/mach-omap2/smartreflex.c | 251
arch/arm/mach-omap2/smartreflex.h | 48 ++--
3 files changed, 182 insertions(+), 125 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c00925d..ba9f899 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -55,6 +55,7 @@ struct omap_sr {
/* sr_list contains all the instances of smartreflex module */
static LIST_HEAD(sr_list);
+static struct omap_smartreflex_class_data *sr_class;
I think the class should be part of 'struct omap_sr'. This should be
coded in a way to allow a different class type or each SR module (even
if that is never useful in practice.)
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 06/16] OMAP3: PM: Smartreflex class related changes for smartreflex.c
Thara Gopinath th...@ti.com writes:
OMAP3 smartreflex modules are capable of two different classes
of implementaion -
Class-2: Continuous Software Calibration
Class-3: Continuous Hardware Calibration.
OMAP3 along with T2/Gaia supports the Class 3 implementaion.
With a different PMIC it can support Class 2 implementaion also.
The idea behind this patch is that smartreflex.c should be able
to support both the classes of Smartreflex and the class specific
details for smartreflex should stay out of this file in a separate
class file.
This patch introduces smartreflex class specific hooks in
smartreflex.c. This patch only takes care of smartreflex enable
disable hooks which differ between Class 2 and Class 3. There
are some register setting changes between both the classes which
will be taken care of in a later patch.
This will form the base for adding class specific
drivers in later patches.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |8 +-
arch/arm/mach-omap2/smartreflex.c | 251
arch/arm/mach-omap2/smartreflex.h | 48 ++--
3 files changed, 182 insertions(+), 125 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c00925d..ba9f899 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -55,6 +55,7 @@ struct omap_sr {
/* sr_list contains all the instances of smartreflex module */
static LIST_HEAD(sr_list);
+static struct omap_smartreflex_class_data *sr_class;
#define SR_REGADDR(offs) (sr-srbase_addr + offset)
@@ -388,14 +389,86 @@ static int sr_reset_voltage(int srid)
return 0;
}
-static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
+static void sr_start_vddautocomap(int srid)
Either in this patch or in an additional patch (previous to this one)
can you fix the name of these autocomp functions: *_vddautocomap -
*_vddautocomp. I don't think comap means anything.
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 03/16] OMAP3: PM: Convert smartreflex driver into a platform driver using hwmods and omap-device layer
Thara Gopinath th...@ti.com writes:
This patch converts the exisitng smartreflex library into a
platform driver with device , driver registrations using hardware mods.
As part of this Ntarget values are passed as platform data.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+static int __devinit omap_smartreflex_probe(struct platform_device *pdev)
This can be __init when using platform_driver_probe()...
[...]
+static struct platform_driver smartreflex_driver = {
+ .probe = omap_smartreflex_probe,
and shouldn't need to be listed here either, since it will be __init
and disappear after boot.
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 11/16] OMAP3: PM: Configurations for Smartreflex Class 2 and Smartreflex Class 3
Thara Gopinath th...@ti.com writes:
There are two separate modules in SmartReflex-AVS :
MinMaxAvg module and Error module. Class3 uses the Error module only.
In Class2 you can choose between either module since it is software based.
The registers are mapped to the modules as followed:
MinMaxAvg module: AccumData, MinMaxAvgEnable, MinMaxAvgValid,
MinMaxAvgAccumValid, SenVal, SenMin, SenMax, SenAverage,
AverageWeight, MCUAccum, MCUValid, MCUBounds.
Error module: SenNGain, SenPGain, SenPRN, SenNRN, AvgError,
SenError, VPBounds, ErrWeight, ErrMaxLimit, ErrMinLimit.
Shared between both: SRClkLength, SREnable, SenEnable, SenNEnable,
SenPEnable, DelayCtrl, MCUDisableAck, ClkActivity.
This patch introduces class specific configuration of registers in
smartreflex.c
This also allows for choosing between Error module and Minmaxavg module
for Class 2 SR. This patch allows allows for registering for smartreflex
interrupt handler and notification of interrupts in case requested by
the smartreflex class driver.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |1 +
arch/arm/mach-omap2/smartreflex.c| 199
--
arch/arm/mach-omap2/smartreflex.h| 24 -
3 files changed, 186 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 8e3b530..aae88b6 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -43,6 +43,7 @@ static int sr_class3_disable(int id)
struct omap_smartreflex_class_data class3_data = {
.enable = sr_class3_enable,
.disable = sr_class3_disable,
+ .class_type = SR_CLASS3,
};
static int __init sr_class3_init(void)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index f7c1182..96dc76b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -38,6 +38,12 @@ struct omap_sr {
int is_sr_reset;
int is_autocomp_active;
u32 clk_length;
+ u32 err_weight;
+ u32 err_minlimit;
+ u32 err_maxlimit;
+ u32 accum_data;
+ u32 senn_avgweight;
+ u32 senp_avgweight;
void __iomem*srbase_addr;
unsigned intirq;
struct platform_device *pdev;
@@ -106,6 +112,24 @@ static void sr_clk_disable(struct omap_sr *sr)
sr-is_sr_reset = 1;
}
+static irqreturn_t sr_omap_isr(int irq, void *data)
+{
+ struct omap_sr *sr_info = (struct omap_sr *)data;
+ u32 status;
+
+ /* Read the status bits */
+ status = sr_read_reg(sr_info, ERRCONFIG);
+
+ /* Clear them by writing back */
+ sr_write_reg(sr_info, ERRCONFIG, status);
+
+ /* Call the class driver notify function if registered*/
+ if (sr_class-class_type == SR_CLASS2 sr_class-notify)
+ sr_class-notify(sr_info-srid, status);
+
+ return IRQ_HANDLED;
+}
+
static void sr_set_clk_length(struct omap_sr *sr)
{
struct clk *sys_ck;
@@ -137,50 +161,96 @@ static void sr_set_clk_length(struct omap_sr *sr)
}
}
+static void sr_set_regfields(struct omap_sr *sr)
+{
+ /*
+ * For time being these values are defined in smartreflex.h
+ * and populated during init. May be they can be moved to board
+ * file or pmic specific data structure. In that case these structure
+ * fields will have to be populated using the pdata or pmic structure.
+ */
+ if (cpu_is_omap343x()) {
+ sr-err_weight = OMAP3430_SR_ERRWEIGHT;
+ sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
+ sr-accum_data = OMAP3430_SR_ACCUMDATA;
+ if (sr-srid == SR1) {
+ sr-err_minlimit = OMAP3430_SR1_ERRMINLIMIT;
+ sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
+ sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
+ } else {
+ sr-err_minlimit = OMAP3430_SR2_ERRMINLIMIT;
+ sr-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
+ sr-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
+ }
+ }
+ /* TODO: 3630 and Omap4 specific bit field values */
+}
+
static void sr_configure(struct omap_sr *sr)
{
u32 sr_config;
u32 senp_en , senn_en;
struct omap_smartreflex_data *pdata = sr-pdev-dev.platform_data;
+ /* Common settings for SR Class3 and SR Class2 */
if (sr-clk_length == 0)
sr_set_clk_length(sr);
senp_en = pdata-senp_mod;
senn_en = pdata-senn_mod;
- if (sr-srid == SR1) {
- sr_config =
Re: [PATCH 12/16] OMAP3: PM: Support for enabling smartreflex autocompensation by default.
Thara Gopinath th...@ti.com writes:
This patch adds support to pdata enable smartreflex autocompenstion
during init based on init_enable flag passed as pdata.
This patch also adds enabling of autocompensation by
default (setting init_enable flag to true) in case of ES3.1
OMAP3430 chip. In the current implementation
this step is kept in smartreflex.c itself.Later an API can be added
so that the decision to enable autocompensation by default
can be passed from the corresponding board files.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 32
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 96dc76b..085dd05 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -477,9 +477,15 @@ void omap_sr_register_class(struct
omap_smartreflex_class_data *class_data)
sr_class = class_data;
/*
- * Register the interrupt handler incase requested by the class driver
+ * Check if any SR module needs to be enabled as part of init.
+ * In case the probe for the SR module is not yet called the enable
+ * will not be done here but will be done in the probe whenever
+ * it gets called. Also register the interrupt handler incase
+ * requested by the class driver.
*/
list_for_each_entry(sr_info, sr_list, node) {
+ struct omap_smartreflex_data *pdata =
+ sr_info-pdev-dev.platform_data;
if (sr_class-class_type == SR_CLASS2
sr_class-notify_flags sr_info-irq) {
char name[SMARTREFLEX_NAME_LEN];
@@ -496,6 +502,8 @@ void omap_sr_register_class(struct
omap_smartreflex_class_data *class_data)
return;
}
}
+ if (pdata-init_enable)
+ sr_start_vddautocomap(sr_info-srid);
I think this flag is better named enable_on_init.
}
}
@@ -562,11 +570,15 @@ static int __devinit omap_smartreflex_probe(struct
platform_device *pdev)
list_add(sr_info-node, sr_list);
/*
- * Register interrrupt handler if smartreflex class driver is already
- * registered and has requested for interrupts. This will be attempted
+ * Enable the smartreflex module if init_enable flag is set and
+ * if the class driver is registered. Also Register interrrupt handler
+ * if smartreflex class driver is already registered and has
+ * requested for interrupts. This will be attempted
* in the class driver register again if it does not happen here.
*/
if (sr_class) {
+ struct omap_smartreflex_data *pdata = pdev-dev.platform_data;
+
if (sr_class-class_type == SR_CLASS2
sr_class-notify_flags sr_info-irq) {
sprintf(name, sr%d, sr_info-srid);
@@ -580,6 +592,8 @@ static int __devinit omap_smartreflex_probe(struct
platform_device *pdev)
return ret;
}
}
+ if (pdata-init_enable)
+ sr_start_vddautocomap(sr_info-srid);
}
As with the duplicate request_irq() in previous patch, I don't follow
why it's the start is needed twice.
Is it to handle the case where no class driver is installed?
pr_info(SmartReflex driver initialized\n);
@@ -782,7 +796,17 @@ static int __init omap_devinit_smartreflex(void)
if (WARN_ON(!sr_data))
return -ENOMEM;
- sr_data-init_enable = false;
+ /*
+ * Enable the SR module by default if it is a OMAP3430
+ * ES3.1 chip
You should add a comment about why: starting with ES3.1, efuse values can be
trusted?
+ */
+ if (cpu_is_omap343x()) {
+ if (omap_rev() == OMAP3430_REV_ES3_1)
+ sr_data-init_enable = true;
+ else
+ sr_data-init_enable = false;
+ } else
+ sr_data-init_enable = false;
sr_data-device_enable = omap_device_enable;
sr_data-device_shutdown = omap_device_shutdown;
sr_data-device_idle = omap_device_idle;
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 14/16] OMAP3: PM: Implement latest h/w recommendations for SR and VP registers and SR VP enable disable sequence.
Thara Gopinath th...@ti.com writes:
This patch introduces OMAP3 specific values for Smartreflex and
Voltage processor registers as per the latest TI recommendations.
This patch also improves the smartreflex and voltage processor
enable disable sequences as per the latest recommendations.
These recommendations were first formed based on experimentations
on Nokia Rover platform and were implemented in the Rover code
base first by Nishanth Menon and Paul Walmsley.
I think this was pointed out by others, but Rover should be replaced
with n900.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 65 -
arch/arm/mach-omap2/smartreflex.h |6 +-
arch/arm/mach-omap2/voltage.c | 95 ++--
arch/arm/mach-omap2/voltage.h | 16 ---
4 files changed, 142 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 8a4c48b..ca2223d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -24,6 +24,7 @@
#include linux/io.h
#include linux/list.h
#include linux/debugfs.h
+#include linux/delay.h
#include plat/control.h
#include plat/omap_hwmod.h
@@ -32,6 +33,7 @@
#include smartreflex.h
#define SMARTREFLEX_NAME_LEN 16
+#define SR_DISABLE_TIMEOUT 200
struct omap_sr {
int srid;
@@ -184,11 +186,9 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
if (sr-srid == SR1) {
- sr-err_minlimit = OMAP3430_SR1_ERRMINLIMIT;
sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
} else {
- sr-err_minlimit = OMAP3430_SR2_ERRMINLIMIT;
sr-senn_avgweight = OMAP3430_SR2_SENNAVGWEIGHT;
sr-senp_avgweight = OMAP3430_SR2_SENPAVGWEIGHT;
}
@@ -280,11 +280,6 @@ static void sr_start_vddautocomap(int srid)
return;
}
- if (sr-is_sr_reset == 1) {
- sr_clk_enable(sr);
- sr_configure(sr);
- }
-
sr-is_autocomp_active = 1;
if (!sr_class-enable(srid)) {
sr-is_autocomp_active = 0;
@@ -351,8 +346,20 @@ int sr_enable(int srid, u32 target_opp_no)
return false;
}
- nvalue_reciprocal = pdata-sr_nvalue[target_opp_no - 1];
+ /*
+ * For OMAP3430 errminlimit is dependent on opp. So choose
+ * it appropriately
+ */
+ if (cpu_is_omap343x())
+ sr-err_minlimit = (target_opp_no 2) ?
+ OMAP3430_SR_ERRMINLIMIT_HIGHOPP :
+ OMAP3430_SR_ERRMINLIMIT_LOWOPP;
+
+ /* Enable the clocks and configure SR */
+ sr_clk_enable(sr);
+ sr_configure(sr);
+ nvalue_reciprocal = pdata-sr_nvalue[target_opp_no - 1];
if (nvalue_reciprocal == 0) {
pr_notice(OPP%d doesn't support SmartReflex\n,
target_opp_no);
@@ -375,10 +382,44 @@ int sr_enable(int srid, u32 target_opp_no)
void sr_disable(int srid)
{
struct omap_sr *sr = _sr_lookup(srid);
+ int timeout = 0;
+
+ /* Check if SR is already disabled. If yes do nothing */
+ if (!(sr_read_reg(sr, SRCONFIG) SRCONFIG_SRENABLE))
+ return;
+
+ /* Enable MCUDisableAcknowledge interrupt */
+ sr_modify_reg(sr, ERRCONFIG,
+ ERRCONFIG_MCUDISACKINTEN, ERRCONFIG_MCUDISACKINTEN);
- sr-is_sr_reset = 1;
/* SRCONFIG - disable SR */
- sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, ~SRCONFIG_SRENABLE);
+ sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, 0x0);
+
+ /* Disable all other SR interrupts and clear the status */
+ sr_modify_reg(sr, ERRCONFIG,
+ (ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUVALIDINTEN |
+ ERRCONFIG_MCUBOUNDINTEN | ERRCONFIG_VPBOUNDINTEN),
+ (ERRCONFIG_MCUACCUMINTST | ERRCONFIG_MCUVALIDINTST |
+ ERRCONFIG_MCUBOUNDINTST | ERRCONFIG_VPBOUNDINTST));
+
+ /* Wait for SR to be disabled.
+ * wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
+ */
+ while ((timeout SR_DISABLE_TIMEOUT)
+ (!(sr_read_reg(sr, ERRCONFIG) ERRCONFIG_MCUDISACKINTST))) {
+
+ udelay(1);
+ timeout++;
+ }
Please use omap_test_timeout() from plat/common.h
+ if (timeout == SR_DISABLE_TIMEOUT)
+ pr_warning(SR%d disable timedout\n, srid);
+
+ /* Disable MCUDisableAcknowledge interrupt clear pending interrupt
+ * Also enable VPBOUND interrrupt
+ */
+ sr_modify_reg(sr,
Re: [PATCH 15/16] OMAP3: PM: VP force update method of voltage scaling
Thara Gopinath th...@ti.com writes:
This patch introduces VP force update method of voltage scaling
and enables it by default. The older method of vc bypass is now
configuratble through a menu config option. VP force update is the
hardware recommended method of voltage scaling.
Signed-off-by: Thara Gopinath th...@ti.com
This should be a runtime option intead of a compile-time option.
Default should be HW recommended method, but board code should be able
to override.
Only did a quick glance at this, an some minor coding style issues below...
---
arch/arm/mach-omap2/voltage.c | 149
+++--
arch/arm/mach-omap2/voltage.h |1 +
arch/arm/plat-omap/Kconfig| 19 +
3 files changed, 162 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 49167c0..4f325af 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -29,7 +29,8 @@
#include prm-regbits-34xx.h
#include voltage.h
-#define VP_IDLE_TIMEOUT 200
+#define VP_IDLE_TIMEOUT 200
+#define VP_TRANXDONE_TIMEOUT 300
/*
* OMAP3 Voltage controller SR parameters. TODO: Pass this info as part of
@@ -70,6 +71,7 @@ struct vp_reg_info {
u32 vp_vddmin;
u32 vp_vddmax;
u32 vp_timeout;
+ u32 vp_tranxdone_status;
};
static struct vp_reg_info *vp_reg;
/*
@@ -299,6 +301,8 @@ static void __init vp_reg_configure(int vp_id)
OMAP3430_VDDMIN_SHIFT);
vp_reg[vp_id].vp_vddmax = (OMAP3_VP1_VLIMITTO_VDDMAX
OMAP3430_VDDMAX_SHIFT);
+ vp_reg[vp_id].vp_tranxdone_status =
+ OMAP3430_VP1_TRANXDONE_ST;
} else if (vp_id == VP2) {
/*
* OMAP3430 has error gain varying btw higher and
@@ -312,6 +316,8 @@ static void __init vp_reg_configure(int vp_id)
OMAP3430_VDDMIN_SHIFT);
vp_reg[vp_id].vp_vddmax = (OMAP3_VP2_VLIMITTO_VDDMAX
OMAP3430_VDDMAX_SHIFT);
+ vp_reg[vp_id].vp_tranxdone_status =
+ OMAP3430_VP2_TRANXDONE_ST;
} else {
pr_warning(Voltage processor%d does not exisit\
in OMAP3 \n, vp_id);
@@ -346,6 +352,131 @@ static void __init vp_reg_configure(int vp_id)
/* TODO Extend this for OMAP4 ?? Or need a separate file */
}
+#ifdef CONFIG_OMAP_VOLT_VPFORCEUPDATE
+/* VP force update method of voltage scaling */
+static int vp_forceupdate_scale_voltage(u32 vdd, u8 target_vsel,
+ u8 current_vsel)
+{
+ u32 smps_steps = 0, smps_delay = 0;
+ u32 vpconfig;
+ int timeout = 0;
+ int vp_id = vdd - 1;
+
+ if (!((vdd == VDD1_OPP) || (vdd == VDD2_OPP))) {
+ pr_warning(Wrong vdd id passed to vp forceupdate\n);
+ return false;
+ }
+
+ smps_steps = abs(target_vsel - current_vsel);
+
+ /* OMAP3430 has errorgain varying btw higher and lower opp's */
+ if (cpu_is_omap34xx()) {
+ if (vdd == VDD1_OPP) {
+ u32 vc_cmdval0;
+
+ vc_cmdval0 = voltage_read_reg(vc_reg.vc_cmdval0_reg);
+ vc_cmdval0 = ~VC_CMD_ON_MASK;
+ vc_cmdval0 |= (target_vsel VC_CMD_ON_SHIFT);
+ voltage_write_reg(vc_reg.vc_cmdval0_reg, vc_cmdval0);
+ vp_reg[vp_id].vp_errorgain = (((get_vdd1_opp() 2) ?
+ (OMAP3_VP_CONFIG_ERRORGAIN_HIGHOPP) :
+ (OMAP3_VP_CONFIG_ERRORGAIN_LOWOPP))
+ OMAP3430_ERRORGAIN_SHIFT);
+ } else if (vdd == VDD2_OPP) {
+ u32 vc_cmdval1;
+
+ vc_cmdval1 = voltage_read_reg(vc_reg.vc_cmdval1_reg);
+ vc_cmdval1 = ~VC_CMD_ON_MASK;
+ vc_cmdval1 |= (target_vsel VC_CMD_ON_SHIFT);
+ voltage_write_reg(vc_reg.vc_cmdval1_reg, vc_cmdval1);
+ vp_reg[vp_id].vp_errorgain = (((get_vdd2_opp() 2) ?
+ (OMAP3_VP_CONFIG_ERRORGAIN_HIGHOPP) :
+ (OMAP3_VP_CONFIG_ERRORGAIN_LOWOPP))
+ OMAP3430_ERRORGAIN_SHIFT);
+ }
+ }
+
+ /* Clear all pending TransactionDone interrupt/status. Typical latency
+ * is 3us
+ */
+ while (timeout++ VP_TRANXDONE_TIMEOUT) {
+ voltage_write_reg(PRM_IRQSTATUS_REG,
+ vp_reg[vp_id].vp_tranxdone_status);
+ if (!(voltage_read_reg(PRM_IRQSTATUS_REG)
+
RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Thomas Gleixner
Sent: Monday, March 01, 2010 1:02 PM
To: LKML
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: [PATCH] mmc: omap_hsmmc: Fix conditional locking
Conditional locking on (!in_interrupt()) is broken by design and there
is no reason to keep the host-irq_lock across the call to
mmc_request_done(). Also the host-protect_card magic hack does not
depend on the context
Can you please elaborate why the existing logic is broken?
It locks at the new request and unlocks just before issuing the cmd. Further
IRQ handler has these calls hence the !in_interrupt check.
How does this patch improve that? In fact with your patch for a data
transfer cmd there are several lock-unlock calls.
Fix the mess by dropping host-irq_lock before calling
mmc_request_done().
Signed-off-by: Thomas Gleixner t...@linutronix.de
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..99a3383 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -468,14 +468,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
if (host-use_dma)
cmdreg |= DMA_EN;
- /*
- * In an interrupt context (i.e. STOP command), the spinlock is
unlocked
- * by the interrupt handler, otherwise (i.e. for a new request) it
is
- * unlocked here.
- */
- if (!in_interrupt())
- spin_unlock_irqrestore(host-irq_lock, host-flags);
-
OMAP_HSMMC_WRITE(host-base, ARG, cmd-arg);
OMAP_HSMMC_WRITE(host-base, CMD, cmdreg);
}
@@ -506,7 +498,9 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
}
host-mrq = NULL;
+ spin_unlock(host-irq_lock);
mmc_request_done(host-mmc, mrq);
+ spin_lock(host-irq_lock);
return;
}
@@ -523,7 +517,9 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
if (!data-stop) {
host-mrq = NULL;
+ spin_unlock(host-irq_lock);
mmc_request_done(host-mmc, data-mrq);
+ spin_lock(host-irq_lock);
return;
}
omap_hsmmc_start_command(host, data-stop, NULL);
@@ -551,7 +547,9 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
}
if ((host-data == NULL !host-response_busy) || cmd-error) {
host-mrq = NULL;
+ spin_unlock(host-irq_lock);
mmc_request_done(host-mmc, cmd-mrq);
+ spin_lock(host-irq_lock);
}
}
@@ -1077,37 +1075,31 @@ static void omap_hsmmc_request(struct mmc_host
*mmc, struct mmc_request *req)
struct omap_hsmmc_host *host = mmc_priv(mmc);
int err;
+ spin_lock_irqsave(host-irq_lock, host-flags);
/*
- * Prevent races with the interrupt handler because of unexpected
- * interrupts, but not if we are already in interrupt context i.e.
- * retries.
+ * Protect the card from I/O if there is a possibility
+ * it can be removed.
*/
- if (!in_interrupt()) {
- spin_lock_irqsave(host-irq_lock, host-flags);
- /*
- * Protect the card from I/O if there is a possibility
- * it can be removed.
- */
- if (host-protect_card) {
- if (host-reqs_blocked 3) {
- /*
- * Ensure the controller is left in a
consistent
- * state by resetting the command and data
state
- * machines.
- */
- omap_hsmmc_reset_controller_fsm(host, SRD);
- omap_hsmmc_reset_controller_fsm(host, SRC);
- host-reqs_blocked += 1;
- }
- req-cmd-error = -EBADF;
- if (req-data)
- req-data-error = -EBADF;
- spin_unlock_irqrestore(host-irq_lock,
host-flags);
- mmc_request_done(mmc, req);
- return;
- } else if (host-reqs_blocked)
- host-reqs_blocked = 0;
- }
+ if (host-protect_card) {
+ if (host-reqs_blocked 3) {
+ /*
+ * Ensure the controller is left in a consistent
+ * state by resetting the command and data state
+ * machines.
+ */
+ omap_hsmmc_reset_controller_fsm(host, SRD);
+ omap_hsmmc_reset_controller_fsm(host, SRC);
+ host-reqs_blocked +=
[PATCH] Add support for OMAP3Stalker boards
(SBC3530, OMAP3 STALKER) +/* Maintainer: Jason Lam -...@ema-tech.com */ + .phys_io = 0x4800, + .io_pg_offst = ((0xfa00) 18) 0xfffc, + .boot_params = 0x8100, + .map_io = omap3_stalker_map_io, + .init_irq = omap3_stalker_init_irq, + .init_machine = omap3_stalker_init, + .timer = omap_timer, +MACHINE_END + -- 1.5.4.3 __ Information from ESET Smart Security, version of virus signature database 4910 (20100302) __ The message was checked by ESET Smart Security. http://www.eset.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] serial: Add OMAP high-speed UART driver.
-Original Message- From: Shilimkar, Santosh Sent: Tuesday, March 02, 2010 8:43 PM To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. -Original Message- From: G, Manjunath Kondaiah Sent: Tuesday, March 02, 2010 8:34 PM To: Shilimkar, Santosh; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux- ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. Santosh, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, March 02, 2010 7:34 PM To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux-ser...@vger.kernel.org; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; Kevin Hilman; Olof Johansson Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver. snip snip -- CDAC is a shadow register used for monitoring the DMA channel. I think it would be a lot simpler if omap_start_dma() always resets CDAC to 0, and the UART driver just not set it explicitly. This seems to be better option than exposing CDAC read/write API to other drivers since user need to write '0' before starting any DMA transfer which can be be done in omap_start_dma(). I am wondering how other drivers are using DMA transfer API's without resetting CDAC to zero. It's needed only if some one is interested in that count. UART seems to using this counter where as other driver don't. Why do you think drivers need to know about counter value ? Reading of non zero value(after reset to zero and enabling dma channel) from CDAC register indicates that, DMA transfer has started and user can rely on DMA4_CCENi and DMA4_CCFNi element and frame counters. If the CDAC value is zero even after starting DMA channel, indicates error. Not necessary. The DMA can still wait for the hw sync signal and the CDAC can remain 0 if the hw sync in not received. This will be any way returned by DMA error ( SYNC lost) This register was mainly suppose to be used for debug purposes. As per TRM, CDAC can also be used for monitoring synchroized data transfer apart from hw sync signal monitoring. Anyway, we have are aligned to set this register to zero in omap_start_dma() which will over ride this patch. Regards, Manjunath -- 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] Add OMAP3 Stalker board LK-S defconfig
+# CONFIG_DEBUG_WRITECOUNT is not set +# CONFIG_DEBUG_MEMORY_INIT is not set +# CONFIG_DEBUG_LIST is not set +# CONFIG_DEBUG_SG is not set +# CONFIG_DEBUG_NOTIFIERS is not set +# CONFIG_DEBUG_CREDENTIALS is not set +# CONFIG_BOOT_PRINTK_DELAY is not set +# CONFIG_RCU_TORTURE_TEST is not set +# CONFIG_RCU_CPU_STALL_DETECTOR is not set +# CONFIG_BACKTRACE_SELF_TEST is not set +# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set +# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set +# CONFIG_FAULT_INJECTION is not set +# CONFIG_LATENCYTOP is not set +# CONFIG_SYSCTL_SYSCALL_CHECK is not set +# CONFIG_PAGE_POISONING is not set +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_TRACING_SUPPORT=y +CONFIG_FTRACE=y +# CONFIG_FUNCTION_TRACER is not set +# CONFIG_IRQSOFF_TRACER is not set +# CONFIG_SCHED_TRACER is not set +# CONFIG_ENABLE_DEFAULT_TRACERS is not set +# CONFIG_BOOT_TRACER is not set +CONFIG_BRANCH_PROFILE_NONE=y +# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set +# CONFIG_PROFILE_ALL_BRANCHES is not set +# CONFIG_STACK_TRACER is not set +# CONFIG_KMEMTRACE is not set +# CONFIG_WORKQUEUE_TRACER is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_DYNAMIC_DEBUG is not set +# CONFIG_SAMPLES is not set +CONFIG_HAVE_ARCH_KGDB=y +# CONFIG_KGDB is not set +CONFIG_ARM_UNWIND=y +# CONFIG_DEBUG_USER is not set +# CONFIG_DEBUG_ERRORS is not set +# CONFIG_DEBUG_STACK_USAGE is not set +CONFIG_DEBUG_LL=y +# CONFIG_EARLY_PRINTK is not set +# CONFIG_DEBUG_ICEDCC is not set +# CONFIG_OC_ETM is not set + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set +# CONFIG_SECURITYFS is not set +# CONFIG_DEFAULT_SECURITY_SELINUX is not set +# CONFIG_DEFAULT_SECURITY_SMACK is not set +# CONFIG_DEFAULT_SECURITY_TOMOYO is not set +CONFIG_DEFAULT_SECURITY_DAC=y +CONFIG_DEFAULT_SECURITY= +CONFIG_CRYPTO=y + +# +# Crypto core or helper +# +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_ALGAPI2=y +CONFIG_CRYPTO_AEAD2=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_BLKCIPHER2=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_RNG2=y +CONFIG_CRYPTO_PCOMP=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_MANAGER2=y +# CONFIG_CRYPTO_GF128MUL is not set +# CONFIG_CRYPTO_NULL is not set +CONFIG_CRYPTO_WORKQUEUE=y +# CONFIG_CRYPTO_CRYPTD is not set +# CONFIG_CRYPTO_AUTHENC is not set +# CONFIG_CRYPTO_TEST is not set + +# +# Authenticated Encryption with Associated Data +# +# CONFIG_CRYPTO_CCM is not set +# CONFIG_CRYPTO_GCM is not set +# CONFIG_CRYPTO_SEQIV is not set + +# +# Block modes +# +CONFIG_CRYPTO_CBC=y +# CONFIG_CRYPTO_CTR is not set +# CONFIG_CRYPTO_CTS is not set +CONFIG_CRYPTO_ECB=m +# CONFIG_CRYPTO_LRW is not set +CONFIG_CRYPTO_PCBC=m +# CONFIG_CRYPTO_XTS is not set + +# +# Hash modes +# +# CONFIG_CRYPTO_HMAC is not set +# CONFIG_CRYPTO_XCBC is not set +# CONFIG_CRYPTO_VMAC is not set + +# +# Digest +# +CONFIG_CRYPTO_CRC32C=y +# CONFIG_CRYPTO_GHASH is not set +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=y +# CONFIG_CRYPTO_MICHAEL_MIC is not set +# CONFIG_CRYPTO_RMD128 is not set +# CONFIG_CRYPTO_RMD160 is not set +# CONFIG_CRYPTO_RMD256 is not set +# CONFIG_CRYPTO_RMD320 is not set +# CONFIG_CRYPTO_SHA1 is not set +# CONFIG_CRYPTO_SHA256 is not set +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_TGR192 is not set +# CONFIG_CRYPTO_WP512 is not set + +# +# Ciphers +# +# CONFIG_CRYPTO_AES is not set +# CONFIG_CRYPTO_ANUBIS is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_CAMELLIA is not set +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_FCRYPT is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_SALSA20 is not set +# CONFIG_CRYPTO_SEED is not set +# CONFIG_CRYPTO_SERPENT is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_TWOFISH is not set + +# +# Compression +# +# CONFIG_CRYPTO_DEFLATE is not set +# CONFIG_CRYPTO_ZLIB is not set +# CONFIG_CRYPTO_LZO is not set + +# +# Random Number Generation +# +# CONFIG_CRYPTO_ANSI_CPRNG is not set +CONFIG_CRYPTO_HW=y +# CONFIG_BINARY_PRINTF is not set + +# +# Library routines +# +CONFIG_BITREVERSE=y +CONFIG_GENERIC_FIND_LAST_BIT=y +CONFIG_CRC_CCITT=y +# CONFIG_CRC16 is not set +# CONFIG_CRC_T10DIF is not set +# CONFIG_CRC_ITU_T is not set +CONFIG_CRC32=y +# CONFIG_CRC7 is not set +CONFIG_LIBCRC32C=y +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y +CONFIG_DECOMPRESS_GZIP=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT=y +CONFIG_HAS_DMA=y +CONFIG_NLATTR=y -- 1.5.4.3 __ Information from ESET Smart Security, version of virus signature database 4910 (20100302) __ The message was checked by ESET Smart Security. http://www.eset.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] OMAP: Zoom3: Fix Zoom3 booting issue
Sergio, -Original Message- From: Aguirre, Sergio Sent: Tuesday, March 02, 2010 9:41 PM To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Manju, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Manjunatha GK Sent: Tuesday, March 02, 2010 7:36 AM To: linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue The commit id 5550bc33a1a9002976022cc794fe8c52ad9a0021 seems to be broken zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630. But, it looks like OMAP3630 UART4 interface and functional clock nodes needs to be added for omap3630. Thus limiting no. of UART's for 3630 to 3 to prevent boot up issues until clock nodes are added for UART4 on OMAP3630. I already tried a similar patch here: http://patchwork.kernel.org/patch/81692/ But as it is really not solving anything, and Tony rejected it, I started working on the needed bits to get UART4 enabled, therefore I have came up with this patch series: - [RFC v3][PATCH 0/6] OMAP3630: UART4 startup (+ new bugfix!) [1] Also, I'm working in my spare time on a cleanup proposal [2], which I'll repost today, given some comments from Kevin. So, if you want to boot, take series [1] and [2], and then you should be able to boot with ttyS0. Sergio, did you test this combination on zoom3? It seems to be not working on zoom3 with ttyS0 and also with ttyS3. Where as, reducing number of uarts(for 3630) to 3 seems to working fine for ttyS3 on zoom3. -Manjunath -- 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] OMAP: Zoom3: Fix Zoom3 booting issue
-Original Message- From: G, Manjunath Kondaiah Sent: Wednesday, March 03, 2010 11:31 AM To: Aguirre, Sergio; linux-omap@vger.kernel.org Cc: Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Sergio, -Original Message- From: Aguirre, Sergio Sent: Tuesday, March 02, 2010 9:41 PM To: G, Manjunath Kondaiah; linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: RE: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue Manju, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Manjunatha GK Sent: Tuesday, March 02, 2010 7:36 AM To: linux-omap@vger.kernel.org Cc: G, Manjunath Kondaiah; Tony Lindgren; Shilimkar, Santosh; Raja, Govindraj Subject: [PATCH] OMAP: Zoom3: Fix Zoom3 booting issue The commit id 5550bc33a1a9002976022cc794fe8c52ad9a0021 seems to be broken zoom3 boot which adds support for UART4 on OMAP4 and OMAP3630. But, it looks like OMAP3630 UART4 interface and functional clock nodes needs to be added for omap3630. Thus limiting no. of UART's for 3630 to 3 to prevent boot up issues until clock nodes are added for UART4 on OMAP3630. I already tried a similar patch here: http://patchwork.kernel.org/patch/81692/ But as it is really not solving anything, and Tony rejected it, I started working on the needed bits to get UART4 enabled, therefore I have came up with this patch series: - [RFC v3][PATCH 0/6] OMAP3630: UART4 startup (+ new bugfix!) [1] Also, I'm working in my spare time on a cleanup proposal [2], which I'll repost today, given some comments from Kevin. So, if you want to boot, take series [1] and [2], and then you should be able to boot with ttyS0. Sergio, did you test this combination on zoom3? It seems to be not working on zoom3 with ttyS0 and also with ttyS3. Where as, reducing number of uarts(for 3630) to 3 seems to working fine for ttyS3 on zoom3. To update further, it seems to be working on zoom3 with ttyS0 with following combination of patches: 1. [RFC,part2,v1,4/4] omap3: zoom 2/3: Change debugboard serial port id [RFC,part2,v1,3/4] omap3: 3630sdp: Explicitly enable all UARTs [RFC,part2,v1,2/4] omap3: zoom2/3 / 3630sdp: Don't init always all uarts [RFC,part2,v1,1/4] omap2/3/4: serial: rename omap_serial_init 2. [RESEND,PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init 3. [RFC,v3,6/6] omap3: serial: Fix uart4 handling for 3630 [RFC,v3,5/6] OMAP3: PRCM: Consider UART4 for 3630 chip in prcm_setup_regs [RFC,v3,4/6] OMAP clock: Add uart4_ick/fck definitions for 3630 [RFC,v3,3/6] ARM: OMAP3630: PRCM: Add UART4 control bits [RFC,v3,2/6] omap2/3/4: serial: Remove condition for getting uart4_phys [RFC,v3,1/6] OMAP3: serial: Check for zero-based physical addr -Manjunath-- 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: [PATCHv3 2/4] Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Tuesday, March 02, 2010 10:54 PM To: Aggarwal, Anuj Cc: t...@atomide.com; linux-omap@vger.kernel.org; broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk Subject: Re: [PATCHv3 2/4] Regulator: OMAP: Modifying Kconfig/Makefile to choose from available PMICs On Tue, Mar 2, 2010 at 12:29 PM, Anuj Aggarwal anuj.aggar...@ti.com wrote: Kconfig is modified for OMAP3 EVM so that user can choose the appropriate PMIC (currently only TWL4030). Config options for other PMICs will be added later on. Makefile is modified so that twl4030-pmic.c gets compiled for the platforms having TWL4030 as the PMIC. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Kconfig | 9 + arch/arm/mach-omap2/Makefile | 1 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a8a3d1e..1974dda 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -77,6 +77,15 @@ config MACH_OMAP3EVM depends on ARCH_OMAP3 select OMAP_PACKAGE_CBB +config PMIC_TWL4030 + bool TWL4030/TPS65950 Power Module + default y + select TWL4030_CORE + select REGULATOR_TWL4030 if REGULATOR + help + Say yes here if you are using the TWL4030/TPS65950 based power module + for the EVM boards. + Any reason to have this user configurable? The boards that depend on it will always need it to be enabled to compile, and the ones that don't always want it disabled. [Aggarwal, Anuj] OMAP3 EVM can have different PMICs like TWL4030, TPS65023, TPS6507x etc; user can configure the kernel accordingly. -- 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
