Re: [PATCH] Fix IGEPv2 second MMC channel power supply
On Mon, 15 Nov 2010 09:32:22 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Hi Enric, So the DUMMY_REGULATOR is only a workaround when a regulator is not defined and shouldn't be used ? Sorry if this is a stupid question but regulator interface is not too clear for me. My understanding is that DUMMY_REGULATOR kicks in when the regulator setup is incomplete, and when it's better to fix things behind the user's back rather than leaving him with a broken device. The reality is this : --- | 3V3 | | 1V8 | --- | | - | WIFI/BT | - | ( MMC2 at 1V8 ) | OMAP | --- 3V3 is a fixed regulator 1V8 is a fixed regulator (VIO from TWL4030) So, which you think is the right solution ? I think we should provide a fixed regulator to the device, wired to the .vio field of twl4030_platform_data. I'll submit a patch later today, once I get a chance to test it on my board. Cheers, M. -- I'm the slime oozin' out from your TV set... -- 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
[PATCHv2]OMAP PM:MPU/DMA Latency constraints
The previous implementation of OMAP interrupt/DMA latency constraints
were implemented using SRF which is obsolete now. This patch has
implemented the same using PM QOS infeastructure. As part of this, API
signature has been changed to take pm qos handle instead of dev pointer
since PM QOS infrastructure takes pm_qos handle to distingush different
latency requests.So each driver is expected to have it's own pm_qos handle.
However it's an opaque handle from driver's point of view as drivers just
need to define a handle and this handle gets initialized automatically when
they make the first mpu/dma latency request.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
The changes are rebased to latest kevin's origin/pm branch and tested
on OMAP ZOOM3.
---
V2: aligned the implementation with latest PM QOS APIs
addressed comments from Kevin Hilman
(https://patchwork.kernel.org/patch/113855/)
V1: Initial Patch
arch/arm/plat-omap/Kconfig|3 +
arch/arm/plat-omap/Makefile |1 +
arch/arm/plat-omap/i2c.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 13 +-
arch/arm/plat-omap/omap-pm-noop.c | 20 +-
arch/arm/plat-omap/omap-pm.c | 316 +
6 files changed, 341 insertions(+), 15 deletions(-)
create mode 100755 arch/arm/plat-omap/omap-pm.c
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 92c5bb7..4ff485e 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -184,6 +184,9 @@ config OMAP_PM_NONE
config OMAP_PM_NOOP
bool No-op/debug PM layer
+config OMAP_PM
+ depends on PM
+ bool OMAP PM layer implementation
endchoice
endmenu
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 3f0a2bb..545a6a1 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -38,3 +38,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+obj-$(CONFIG_OMAP_PM) += omap-pm.o
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5bff9c..eb9a7cb 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -114,7 +114,8 @@ static inline int omap1_i2c_add_bus(int bus_id)
*/
static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
{
- omap_pm_set_max_mpu_wakeup_lat(dev, t);
+ static struct pm_qos_request_list *qos_handle;
+ omap_pm_set_max_mpu_wakeup_lat(qos_handle, t);
}
static struct omap_device_pm_latency omap_i2c_latency[] = {
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index c5b533d..6425e82
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -20,6 +20,7 @@
#include powerdomain.h
#include plat/opp.h
+#include linux/pm_qos_params.h
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
@@ -75,7 +76,8 @@ void omap_pm_if_exit(void);
/**
* omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
- * @dev: struct device * requesting the constraint
+ * @qos_request: handle for the constraint. The pointer should be
+ * initialized to NULL
* @t: maximum MPU wakeup latency in microseconds
*
* Request that the maximum interrupt latency for the MPU to be no
@@ -107,7 +109,8 @@ void omap_pm_if_exit(void);
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);
+int omap_pm_set_max_mpu_wakeup_lat(struct pm_qos_request_list **qos_request,
+ long t);
/**
@@ -174,7 +177,8 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev,
struct device *dev,
/**
* omap_pm_set_max_sdma_lat - set the maximum system DMA transfer start latency
- * @dev: struct device *
+ * @qos_request: handle for the constraint. The pointer should be
+ * initialized to NULL
* @t: maximum DMA transfer start latency in microseconds
*
* Request that the maximum system DMA transfer start latency for this
@@ -199,7 +203,8 @@ int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev,
struct device *dev,
* Returns -EINVAL for an invalid argument, -ERANGE if the constraint
* is not satisfiable, or 0 upon success.
*/
-int omap_pm_set_max_sdma_lat(struct device *dev, long t);
+int omap_pm_set_max_sdma_lat(struct pm_qos_request_list **qos_request,
+ long t);
/**
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index ca75abb..abcf9ae
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -30,19 +30,19 @@
* Device-driver-originated constraints (via board-*.c files)
*/
-int
[PATCH 0/8] OMAP2+: hwmod core upgrades for 2.6.38: first set
This patch series contains upgrades for the OMAP2+ hwmod core code, intended for 2.6.38. Most of these patches were developed in response to use-cases discovered while converting device drivers to use the hwmod code. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. - Paul --- hwmod_a_2.6.38 textdata bss dec hex filename 5708416 472960 5608992 11790368 b3e820 vmlinux.omap2plus_defconfig.orig 5709076 470560 5608992 11788628 b3e154 vmlinux.omap2plus_defconfig.patched Paul Walmsley (7): OMAP2+: io: split omap2_init_common_hw() OMAP2+: hwmod: allow custom pre-shutdown functions OMAP2+: hwmod: add postsetup state OMAP2+: hwmod: add support for per-class custom device reset functions OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock OMAP2+: hwmod: fix a warning, add some docs, remove unused fields Rajendra Nayak (1): OMAP2+: hwmod: Update the sysc_cache in case module context is lost arch/arm/mach-omap2/board-2430sdp.c |3 arch/arm/mach-omap2/board-3430sdp.c |3 arch/arm/mach-omap2/board-3630sdp.c |5 arch/arm/mach-omap2/board-4430sdp.c |3 arch/arm/mach-omap2/board-am3517evm.c|4 arch/arm/mach-omap2/board-apollon.c |3 arch/arm/mach-omap2/board-cm-t35.c |3 arch/arm/mach-omap2/board-cm-t3517.c |3 arch/arm/mach-omap2/board-devkit8000.c |5 arch/arm/mach-omap2/board-generic.c |3 arch/arm/mach-omap2/board-h4.c |3 arch/arm/mach-omap2/board-igep0020.c |4 arch/arm/mach-omap2/board-igep0030.c |4 arch/arm/mach-omap2/board-ldp.c |3 arch/arm/mach-omap2/board-n8x0.c |3 arch/arm/mach-omap2/board-omap3beagle.c |5 arch/arm/mach-omap2/board-omap3evm.c |3 arch/arm/mach-omap2/board-omap3logic.c |3 arch/arm/mach-omap2/board-omap3pandora.c |5 arch/arm/mach-omap2/board-omap3stalker.c |3 arch/arm/mach-omap2/board-omap3touchbook.c |5 arch/arm/mach-omap2/board-omap4panda.c |3 arch/arm/mach-omap2/board-overo.c|5 arch/arm/mach-omap2/board-rx51.c |3 arch/arm/mach-omap2/board-zoom.c |9 - arch/arm/mach-omap2/io.c | 32 ++- arch/arm/mach-omap2/omap_hwmod.c | 264 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 arch/arm/mach-omap2/serial.c |9 - arch/arm/plat-omap/include/plat/io.h |5 arch/arm/plat-omap/include/plat/omap_hwmod.h | 47 +++-- 31 files changed, 302 insertions(+), 153 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] OMAP2+: io: split omap2_init_common_hw()
Split omap2_init_common_hw() into two functions. The first,
omap2_init_common_infrastructure(), initializes the hwmod code and
data, the OMAP PM code, and the clock code and data. The second,
omap2_init_common_devices(), handles any other early device
initialization that, for whatever reason, has not been or cannot be
moved to initcalls or early platform devices.
This patch is required for the hwmod postsetup patch, which allows
board files to change the state that hwmods should be placed into at
the conclusion of the hwmod _setup() function. For example, for a
board whose creators wish to ensure watchdog coverage across the
entire kernel boot process, code to change the watchdog's postsetup
state will be added in the board-*.c file between the
omap2_init_common_infrastructure() and omap2_init_common_devices() function
calls.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-2430sdp.c|3 ++-
arch/arm/mach-omap2/board-3430sdp.c|3 ++-
arch/arm/mach-omap2/board-3630sdp.c|5 +++--
arch/arm/mach-omap2/board-4430sdp.c|3 ++-
arch/arm/mach-omap2/board-am3517evm.c |4 ++--
arch/arm/mach-omap2/board-apollon.c|3 ++-
arch/arm/mach-omap2/board-cm-t35.c |3 ++-
arch/arm/mach-omap2/board-cm-t3517.c |3 ++-
arch/arm/mach-omap2/board-devkit8000.c |5 +++--
arch/arm/mach-omap2/board-generic.c|3 ++-
arch/arm/mach-omap2/board-h4.c |3 ++-
arch/arm/mach-omap2/board-igep0020.c |4 +++-
arch/arm/mach-omap2/board-igep0030.c |4 +++-
arch/arm/mach-omap2/board-ldp.c|3 ++-
arch/arm/mach-omap2/board-n8x0.c |3 ++-
arch/arm/mach-omap2/board-omap3beagle.c|5 +++--
arch/arm/mach-omap2/board-omap3evm.c |3 ++-
arch/arm/mach-omap2/board-omap3logic.c |3 ++-
arch/arm/mach-omap2/board-omap3pandora.c |5 +++--
arch/arm/mach-omap2/board-omap3stalker.c |3 ++-
arch/arm/mach-omap2/board-omap3touchbook.c |5 +++--
arch/arm/mach-omap2/board-omap4panda.c |3 ++-
arch/arm/mach-omap2/board-overo.c |5 +++--
arch/arm/mach-omap2/board-rx51.c |3 ++-
arch/arm/mach-omap2/board-zoom.c |9 +
arch/arm/mach-omap2/io.c | 16
arch/arm/plat-omap/include/plat/io.h |5 +++--
27 files changed, 76 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index b527f8d..7de5e5a 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -143,7 +143,8 @@ static void __init omap_2430sdp_init_irq(void)
{
omap_board_config = sdp2430_config;
omap_board_config_size = ARRAY_SIZE(sdp2430_config);
- omap2_init_common_hw(NULL, NULL);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(NULL, NULL);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..2452dac8c 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -326,7 +326,8 @@ static void __init omap_3430sdp_init_irq(void)
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
- omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index bbcf580..40e816a 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -73,8 +73,9 @@ static void __init omap_sdp_init_irq(void)
{
omap_board_config = sdp_config;
omap_board_config_size = ARRAY_SIZE(sdp_config);
- omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
- h8mbx00u0mer0em_sdrc_params);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..d6f4798 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -217,7 +217,8 @@ static void __init omap_4430sdp_init_irq(void)
{
omap_board_config = sdp4430_config;
omap_board_config_size = ARRAY_SIZE(sdp4430_config);
- omap2_init_common_hw(NULL, NULL);
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(NULL, NULL);
#ifdef CONFIG_OMAP_32K_TIMER
[PATCH 3/8] OMAP2+: hwmod: add postsetup state
Allow board files and OMAP core code to control the state that some or
all of the hwmods end up in at the end of _setup() (called by
omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in
terms of this new postsetup state code.
There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case,
in which all IP blocks should stay enabled after _setup() finishes;
and the MPU watchdog case, in which the watchdog IP block should enter
idle if watchdog coverage of kernel initialization is desired, and
should be disabled otherwise.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Charulatha Varadarajan ch...@ti.com
---
arch/arm/mach-omap2/io.c | 32 ++
arch/arm/mach-omap2/omap_hwmod.c | 82 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 ++
3 files changed, 88 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 90ce77a..39ab1ec 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -311,8 +311,15 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
+{
+ return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
+}
+
void __init omap2_init_common_infrastructure(void)
{
+ u8 postsetup_state;
+
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
@@ -323,6 +330,16 @@ void __init omap2_init_common_infrastructure(void)
omap3xxx_hwmod_init();
else if (cpu_is_omap44xx())
omap44xx_hwmod_init();
+ else
+ pr_err(Could not init hwmod data - unknown SoC\n);
+
+ /* Set the default postsetup state for all hwmods */
+#ifdef CONFIG_PM_RUNTIME
+ postsetup_state = _HWMOD_STATE_IDLE;
+#else
+ postsetup_state = _HWMOD_STATE_ENABLED;
+#endif
+ omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state);
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
@@ -336,25 +353,16 @@ void __init omap2_init_common_infrastructure(void)
else if (cpu_is_omap44xx())
omap4xxx_clk_init();
else
- pr_err(Could not init clock framework - unknown CPU\n);
+ pr_err(Could not init clock framework - unknown SoC\n);
}
-/*
- * XXX Ideally, this function will dwindle into nothingness over time;
- * almost all device init code should be possible through initcalls
- * and other generalized mechanisms
- */
void __init omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
- u8 skip_setup_idle = 0;
-
omap_serial_early_init();
-#ifndef CONFIG_PM_RUNTIME
- skip_setup_idle = 1;
-#endif
- omap_hwmod_late_init(skip_setup_idle);
+ omap_hwmod_late_init();
+
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index c051fa4..683428f 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1313,23 +1313,15 @@ static int _shutdown(struct omap_hwmod *oh)
/**
* _setup - do initial configuration of omap_hwmod
* @oh: struct omap_hwmod *
- * @skip_setup_idle_p: do not idle hwmods at the end of the fn if 1
*
* Writes the CLOCKACTIVITY bits @clockact to the hwmod @oh
- * OCP_SYSCONFIG register. @skip_setup_idle is intended to be used on
- * a system that will not call omap_hwmod_enable() to enable devices
- * (e.g., a system without PM runtime). Returns -EINVAL if the hwmod
- * is in the wrong state or returns 0.
+ * OCP_SYSCONFIG register. Returns -EINVAL if the hwmod is in the
+ * wrong state or returns 0.
*/
static int _setup(struct omap_hwmod *oh, void *data)
{
int i, r;
- u8 skip_setup_idle;
-
- if (!oh || !data)
- return -EINVAL;
-
- skip_setup_idle = *(u8 *)data;
+ u8 postsetup_state;
/* Set iclk autoidle mode */
if (oh-slaves_cnt 0) {
@@ -1349,7 +1341,6 @@ static int _setup(struct omap_hwmod *oh, void *data)
}
}
- mutex_init(oh-_mutex);
oh-_state = _HWMOD_STATE_INITIALIZED;
/*
@@ -1383,8 +1374,25 @@ static int _setup(struct omap_hwmod *oh, void *data)
}
}
- if (!(oh-flags HWMOD_INIT_NO_IDLE) !skip_setup_idle)
+ postsetup_state = oh-_postsetup_state;
+ if (postsetup_state == _HWMOD_STATE_UNKNOWN)
+ postsetup_state = _HWMOD_STATE_ENABLED;
+
+ /*
+* XXX HWMOD_INIT_NO_IDLE does not belong in hwmod data -
+
[PATCH 8/8] OMAP2+: hwmod: Update the sysc_cache in case module context is lost
From: Rajendra Nayak rna...@ti.com
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Identifying if a module has lost context requires atleast one
register read, and since a register read has more latency than
a write, it makes sense to do a blind write always.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 589c282..8a9847e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -211,10 +211,9 @@ static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
/* XXX ensure module interface clock is up */
- if (oh-_sysc_cache != v) {
- oh-_sysc_cache = v;
- omap_hwmod_write(v, oh, oh-class-sysc-sysc_offs);
- }
+ /* Module might have lost context, always update cache and register */
+ oh-_sysc_cache = v;
+ omap_hwmod_write(v, oh, oh-class-sysc-sysc_offs);
}
/**
--
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 6/8] OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
Change the per-hwmod mutex to a spinlock. (The per-hwmod lock
serializes most post-initialization hwmod operations such as enable,
idle, and shutdown.) Spinlocks are needed, because in some cases,
hwmods must be enabled from timer interrupt disabled-context, such as
an ISR. The current use-case that is driving this is the OMAP GPIO
block ISR: it can trigger interrupts even with its clocks disabled,
but these clocks are needed for register accesses in the ISR to succeed.
This patch also effectively reverts commit
848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes
_omap_hwmod_enable() and _omap_hwmod_init() static, renames them back
to _enable() and _idle(), and changes their callers to call the
spinlocking versions. Previously, since omap_hwmod_{enable,init}()
attempted to take mutexes, these functions could not be called while
the timer interrupt was disabled; but now that the functions use
spinlocks and save and restore the IRQ state, it is appropriate to
call them directly.
Kevin Hilman khil...@deeprootsystems.com originally proposed this
patch - thanks Kevin.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 105 +++---
arch/arm/mach-omap2/serial.c |9 --
arch/arm/plat-omap/include/plat/omap_hwmod.h |6 +
3 files changed, 64 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 0e85278..589c282 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -135,6 +135,7 @@
#include linux/err.h
#include linux/list.h
#include linux/mutex.h
+#include linux/spinlock.h
#include plat/common.h
#include plat/cpu.h
@@ -1193,17 +1194,14 @@ static int _reset(struct omap_hwmod *oh)
}
/**
- * _omap_hwmod_enable - enable an omap_hwmod
+ * _enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
* Enables an omap_hwmod @oh such that the MPU can access the hwmod's
- * register target. (This function has a full name --
- * _omap_hwmod_enable() rather than simply _enable() -- because it is
- * currently required by the pm34xx.c idle loop.) Returns -EINVAL if
- * the hwmod is in the wrong state or passes along the return value of
- * _wait_target_ready().
+ * register target. Returns -EINVAL if the hwmod is in the wrong
+ * state or passes along the return value of _wait_target_ready().
*/
-int _omap_hwmod_enable(struct omap_hwmod *oh)
+static int _enable(struct omap_hwmod *oh)
{
int r;
@@ -1250,16 +1248,14 @@ int _omap_hwmod_enable(struct omap_hwmod *oh)
}
/**
- * _omap_hwmod_idle - idle an omap_hwmod
+ * _idle - idle an omap_hwmod
* @oh: struct omap_hwmod *
*
* Idles an omap_hwmod @oh. This should be called once the hwmod has
- * no further work. (This function has a full name --
- * _omap_hwmod_idle() rather than simply _idle() -- because it is
- * currently required by the pm34xx.c idle loop.) Returns -EINVAL if
- * the hwmod is in the wrong state or returns 0.
+ * no further work. Returns -EINVAL if the hwmod is in the wrong
+ * state or returns 0.
*/
-int _omap_hwmod_idle(struct omap_hwmod *oh)
+static int _idle(struct omap_hwmod *oh)
{
if (oh-_state != _HWMOD_STATE_ENABLED) {
WARN(1, omap_hwmod: %s: idle state can only be entered from
@@ -1305,11 +1301,11 @@ static int _shutdown(struct omap_hwmod *oh)
if (oh-class-pre_shutdown) {
prev_state = oh-_state;
if (oh-_state == _HWMOD_STATE_IDLE)
- _omap_hwmod_enable(oh);
+ _enable(oh);
ret = oh-class-pre_shutdown(oh);
if (ret) {
if (prev_state == _HWMOD_STATE_IDLE)
- _omap_hwmod_idle(oh);
+ _idle(oh);
return ret;
}
}
@@ -1382,7 +1378,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
if ((oh-flags HWMOD_INIT_NO_RESET) oh-rst_lines_cnt == 1)
return 0;
- r = _omap_hwmod_enable(oh);
+ r = _enable(oh);
if (r) {
pr_warning(omap_hwmod: %s: cannot be enabled (%d)\n,
oh-name, oh-_state);
@@ -1394,7 +1390,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
/*
* OCP_SYSCONFIG bits need to be reprogrammed after a softreset.
-* The _omap_hwmod_enable() function should be split to
+* The _enable() function should be split to
* avoid the rewrite of the OCP_SYSCONFIG register.
*/
if (oh-class-sysc) {
@@ -1416,7 +1412,7 @@ static int _setup(struct omap_hwmod *oh, void *data)
postsetup_state = _HWMOD_STATE_ENABLED;
if (postsetup_state ==
[PATCH 4/8] OMAP2+: hwmod: add support for per-class custom device reset functions
The standard omap_hwmod.c _reset() code relies on an IP block's
OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This
works for most IP blocks on the chip, but unfortunately not all. For
example, initiator-only IP blocks often don't have any MPU-accessible
OCP-header registers, and therefore the MPU can't write to any
OCP_SYSCONFIG registers in that block. Other IP blocks, such as the
IVA, require a specialized reset sequence.
Since we need to be able to reset these IP blocks as well, allow
custom IP block reset functions to be passed into the hwmod code via a
per-hwmod-class reset function pointer, struct omap_hwmod_class.reset.
If .reset is non-null, then the hwmod _reset() code will call the custom
function instead of the standard OCP SOFTRESET-based code.
As part of this change, rename most of the existing _reset() function
code to _ocp_softreset(), to indicate more clearly that it does not work
for all cases.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Paul Hunt h...@ti.com
Cc: Stanley Liu stanley_...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 38 +++---
arch/arm/plat-omap/include/plat/omap_hwmod.h |9 +-
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 683428f..12a0b9a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1089,7 +1089,7 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
}
/**
- * _reset - reset an omap_hwmod
+ * _ocp_softreset - reset an omap_hwmod via the OCP_SYSCONFIG bit
* @oh: struct omap_hwmod *
*
* Resets an omap_hwmod @oh via the OCP_SYSCONFIG bit. hwmod must be
@@ -1098,12 +1098,13 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
* the module did not reset in time, or 0 upon success.
*
* In OMAP3 a specific SYSSTATUS register is used to get the reset status.
- * Starting in OMAP4, some IPs does not have SYSSTATUS register and instead
+ * Starting in OMAP4, some IPs do not have SYSSTATUS registers and instead
* use the SYSCONFIG softreset bit to provide the status.
*
- * Note that some IP like McBSP does have a reset control but no reset status.
+ * Note that some IP like McBSP do have reset control but don't have
+ * reset status.
*/
-static int _reset(struct omap_hwmod *oh)
+static int _ocp_softreset(struct omap_hwmod *oh)
{
u32 v;
int c = 0;
@@ -1124,7 +1125,7 @@ static int _reset(struct omap_hwmod *oh)
if (oh-flags HWMOD_CONTROL_OPT_CLKS_IN_RESET)
_enable_optional_clocks(oh);
- pr_debug(omap_hwmod: %s: resetting\n, oh-name);
+ pr_debug(omap_hwmod: %s: resetting via OCP SOFTRESET\n, oh-name);
v = oh-_sysc_cache;
ret = _set_softreset(oh, v);
@@ -1164,6 +1165,33 @@ dis_opt_clks:
}
/**
+ * _reset - reset an omap_hwmod
+ * @oh: struct omap_hwmod *
+ *
+ * Resets an omap_hwmod @oh. The default software reset mechanism for
+ * most OMAP IP blocks is triggered via the OCP_SYSCONFIG.SOFTRESET
+ * bit. However, some hwmods cannot be reset via this method: some
+ * are not targets and therefore have no OCP header registers to
+ * access; others (like the IVA) have idiosyncratic reset sequences.
+ * So for these relatively rare cases, custom reset code can be
+ * supplied in the struct omap_hwmod_class .reset function pointer.
+ * Passes along the return value from either _reset() or the custom
+ * reset function - these must return -EINVAL if the hwmod cannot be
+ * reset this way or if the hwmod is in the wrong state, -ETIMEDOUT if
+ * the module did not reset in time, or 0 upon success.
+ */
+static int _reset(struct omap_hwmod *oh)
+{
+ int ret;
+
+ pr_debug(omap_hwmod: %s: resetting\n, oh-name);
+
+ ret = (oh-class-reset) ? oh-class-reset(oh) : _ocp_softreset(oh);
+
+ return ret;
+}
+
+/**
* _omap_hwmod_enable - enable an omap_hwmod
* @oh: struct omap_hwmod *
*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b445ecd..e4c4fd4 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -364,7 +364,7 @@ struct omap_hwmod_omap4_prcm {
* when module is enabled, rather than the default, which is to
* enable autoidle
* HWMOD_SET_DEFAULT_CLOCKACT: program CLOCKACTIVITY bits at startup
- * HWMOD_NO_IDLEST : this module does not have idle status - this is the case
+ * HWMOD_NO_IDLEST: this module does not have idle status - this is the case
* only for few initiator modules on OMAP2 3.
* HWMOD_CONTROL_OPT_CLKS_IN_RESET: Enable all optional clocks during reset.
* This is needed for devices like DSS that require optional clocks enabled
@@ -416,6 +416,7 @@ struct omap_hwmod_omap4_prcm {
* @sysc: device SYSCONFIG/SYSSTATUS register data
* @rev:
[PATCH 7/8] OMAP2+: hwmod: fix a warning, add some docs, remove unused fields
Trivial cleanup and documentation changes on the hwmod code and data:
- resolve the OMAP2430 hwmod data i2c_dev_attr warning
- add some hwmod documentation to indicate flags that should be moved
outside the static hwmod data in a future patch
- remove some unused fields in the struct omap_hwmod_ocp_if and
struct omap_hwmod structures
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 --
arch/arm/plat-omap/include/plat/omap_hwmod.h | 16
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 7cf0d3a..e4b8d7d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -475,8 +475,6 @@ static struct omap_hwmod_class i2c_class = {
.sysc = i2c_sysc,
};
-static struct omap_i2c_dev_attr i2c_dev_attr;
-
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b588f47..62bdb23 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -23,7 +23,7 @@
* - add pinmuxing
* - init_conn_id_bit (CONNID_BIT_VECTOR)
* - implement default hwmod SMS/SDRC flags?
- * - remove unused fields
+ * - move Linux-specific data (non-ROM data) out
*
*/
#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD_H
@@ -159,7 +159,7 @@ struct omap_hwmod_omap2_firewall {
* ADDR_MAP_ON_INIT: Map this address space during omap_hwmod init.
* ADDR_TYPE_RT: Address space contains module register target data.
*/
-#define ADDR_MAP_ON_INIT (1 0)
+#define ADDR_MAP_ON_INIT (1 0)/* XXX does not belong */
#define ADDR_TYPE_RT (1 1)
/**
@@ -200,8 +200,6 @@ struct omap_hwmod_addr_space {
* @fw: interface firewall data
* @addr_cnt: ARRAY_SIZE(@addr)
* @width: OCP data width
- * @thread_cnt: number of threads
- * @max_burst_len: maximum burst length in @width sized words (0 if unlimited)
* @user: initiators using this interface (see OCP_USER_* macros above)
* @flags: OCP interface flags (see OCPIF_* macros above)
*
@@ -221,8 +219,6 @@ struct omap_hwmod_ocp_if {
} fw;
u8 addr_cnt;
u8 width;
- u8 thread_cnt;
- u8 max_burst_len;
u8 user;
u8 flags;
};
@@ -357,9 +353,9 @@ struct omap_hwmod_omap4_prcm {
* HWMOD_SWSUP_MSTDBY: omap_hwmod code should manually bring module in and out
* of standby, rather than relying on module smart-standby
* HWMOD_INIT_NO_RESET: don't reset this module at boot - important for
- * SDRAM controller, etc.
+ * SDRAM controller, etc. XXX probably belongs outside the main hwmod file
* HWMOD_INIT_NO_IDLE: don't idle this module at boot - important for SDRAM
- * controller, etc.
+ * controller, etc. XXX probably belongs outside the main hwmod file
* HWMOD_NO_AUTOIDLE: disable module autoidle (OCP_SYSCONFIG.AUTOIDLE)
* when module is enabled, rather than the default, which is to
* enable autoidle
@@ -459,8 +455,6 @@ struct omap_hwmod_class {
* @_sysc_cache: internal-use hwmod flags
* @_mpu_rt_va: cached register target start address (internal use)
* @_mpu_port_index: cached MPU register target slave ID (internal use)
- * @msuspendmux_reg_id: CONTROL_MSUSPENDMUX register ID (1-6)
- * @msuspendmux_shift: CONTROL_MSUSPENDMUX register bit shift
* @mpu_irqs_cnt: number of @mpu_irqs
* @sdma_reqs_cnt: number of @sdma_reqs
* @opt_clks_cnt: number of @opt_clks
@@ -506,8 +500,6 @@ struct omap_hwmod {
struct list_headnode;
u16 flags;
u8 _mpu_port_index;
- u8 msuspendmux_reg_id;
- u8 msuspendmux_shift;
u8 response_lat;
u8 mpu_irqs_cnt;
u8 sdma_reqs_cnt;
--
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 5/8] OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex
This trivial patch renames omap_hwmod_mutex to _hwmod_list_mutex to indicate
clearly that it is only used for hwmod list manipulation operations.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12a0b9a..0e85278 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,7 +156,8 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
-static DEFINE_MUTEX(omap_hwmod_mutex);
+/* _hwmod_list_mutex protects the list of registered hwmods */
+static DEFINE_MUTEX(_hwmod_list_mutex);
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -874,7 +875,7 @@ static void _shutdown_sysc(struct omap_hwmod *oh)
* @name: find an omap_hwmod by name
*
* Return a pointer to an omap_hwmod by name, or NULL if not found.
- * Caller must hold omap_hwmod_mutex.
+ * Caller must hold _hwmod_list_mutex.
*/
static struct omap_hwmod *_lookup(const char *name)
{
@@ -1502,7 +1503,7 @@ int omap_hwmod_register(struct omap_hwmod *oh)
(oh-_state != _HWMOD_STATE_UNKNOWN))
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
pr_debug(omap_hwmod: %s: registering\n, oh-name);
@@ -1528,7 +1529,7 @@ int omap_hwmod_register(struct omap_hwmod *oh)
ret = 0;
ohr_unlock:
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return ret;
}
@@ -1546,9 +1547,9 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
if (!name)
return NULL;
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
oh = _lookup(name);
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return oh;
}
@@ -1574,13 +1575,13 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
*oh, void *data),
if (!fn)
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
list_for_each_entry(temp_oh, omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
if (ret)
break;
}
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return ret;
}
@@ -1663,10 +1664,10 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: unregistering\n, oh-name);
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
iounmap(oh-_mpu_rt_va);
list_del(oh-node);
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return 0;
}
@@ -2125,7 +2126,7 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh,
const char *name)
* @user: arbitrary context data to pass to the callback function
*
* For each omap_hwmod of class @classname, call @fn. Takes
- * omap_hwmod_mutex to prevent the hwmod list from changing during the
+ * _hwmod_list_mutex to prevent the hwmod list from changing during the
* iteration. If the callback function returns something other than
* zero, the iterator is terminated, and the callback function's return
* value is passed back to the caller. Returns 0 upon success, -EINVAL
@@ -2145,7 +2146,7 @@ int omap_hwmod_for_each_by_class(const char *classname,
pr_debug(omap_hwmod: %s: looking for modules of class %s\n,
__func__, classname);
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
list_for_each_entry(temp_oh, omap_hwmod_list, node) {
if (!strcmp(temp_oh-class-name, classname)) {
@@ -2157,7 +2158,7 @@ int omap_hwmod_for_each_by_class(const char *classname,
}
}
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
if (ret)
pr_debug(omap_hwmod: %s: iterator terminated early: %d\n,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAP: wd_timer: update integration code to use new hwmod changes
Update the OMAP watchdog timer integration code to take advantage of the new hwmod upgrades added by the OMAP2+: hwmod core upgrades for 2.6.38: first set series, posted previously. So that series needs to be applied before these patches. Charu, it would be great if you could take a look at these. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. - Paul --- wdt_2.6.38 textdata bss dec hex filename 5709076 470560 5608992 11788628 b3e154 vmlinux.omap2plus_defconfig.orig 5708892 470560 5608992 11788444 b3e09c vmlinux.omap2plus_defconfig.patched Paul Walmsley (3): OMAP2+: wd_timer: separate watchdog disable code from the rest of mach-omap2/devices.c OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism OMAP: wd_timer: remove old, dead probing code arch/arm/mach-omap2/Makefile |2 - arch/arm/mach-omap2/devices.c | 64 +--- arch/arm/mach-omap2/io.c | 18 arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 ++- arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++- arch/arm/mach-omap2/wd_timer.c | 54 arch/arm/mach-omap2/wd_timer.h | 17 +++ arch/arm/plat-omap/devices.c | 38 - 10 files changed, 108 insertions(+), 109 deletions(-) create mode 100644 arch/arm/mach-omap2/wd_timer.c create mode 100644 arch/arm/mach-omap2/wd_timer.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
[PATCH 1/3] OMAP2+: wd_timer: separate watchdog disable code from the rest of mach-omap2/devices.c
Split the wd_timer disable code out into its own file,
mach-omap2/wd_timer.c; it belongs in its own file rather than
cluttering up devices.c.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Charulatha Varadarajan ch...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/devices.c | 55 +++-
arch/arm/mach-omap2/wd_timer.c | 68
arch/arm/mach-omap2/wd_timer.h | 17 ++
4 files changed, 91 insertions(+), 51 deletions(-)
create mode 100644 arch/arm/mach-omap2/wd_timer.c
create mode 100644 arch/arm/mach-omap2/wd_timer.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b0810b9..fbacad5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o
+common.o wd_timer.o
omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5a0c148..cd6a46a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -33,6 +33,7 @@
#include mux.h
#include control.h
+#include wd_timer.h
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -951,69 +952,23 @@ static inline void omap_init_vout(void) {}
/*-*/
-/*
- * Inorder to avoid any assumptions from bootloader regarding WDT
- * settings, WDT module is reset during init. This enables the watchdog
- * timer. Hence it is required to disable the watchdog after the WDT reset
- * during init. Otherwise the system would reboot as per the default
- * watchdog timer registers settings.
- */
-#define OMAP_WDT_WPS (0x34)
-#define OMAP_WDT_SPR (0x48)
-
static int omap2_disable_wdt(struct omap_hwmod *oh, void *unused)
{
- void __iomem *base;
- int ret;
-
- if (!oh) {
- pr_err(%s: Could not look up wdtimer_hwmod\n, __func__);
- return -EINVAL;
- }
-
- base = omap_hwmod_get_mpu_rt_va(oh);
- if (!base) {
- pr_err(%s: Could not get the base address for %s\n,
- oh-name, __func__);
- return -EINVAL;
- }
-
- /* Enable the clocks before accessing the WDT registers */
- ret = omap_hwmod_enable(oh);
- if (ret) {
- pr_err(%s: Could not enable clocks for %s\n,
- oh-name, __func__);
- return ret;
- }
-
- /* sequence required to disable watchdog */
- __raw_writel(0x, base + OMAP_WDT_SPR);
- while (__raw_readl(base + OMAP_WDT_WPS) 0x10)
- cpu_relax();
-
- __raw_writel(0x, base + OMAP_WDT_SPR);
- while (__raw_readl(base + OMAP_WDT_WPS) 0x10)
- cpu_relax();
-
- ret = omap_hwmod_idle(oh);
- if (ret)
- pr_err(%s: Could not disable clocks for %s\n,
- oh-name, __func__);
-
- return ret;
+ return omap2_wd_timer_disable(oh);
}
static void __init omap_disable_wdt(void)
{
if (cpu_class_is_omap2())
omap_hwmod_for_each_by_class(wd_timer,
- omap2_disable_wdt, NULL);
+omap2_disable_wdt, NULL);
return;
}
static int __init omap2_init_devices(void)
{
- /* please keep these calls, and their implementations above,
+ /*
+* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
omap_disable_wdt();
diff --git a/arch/arm/mach-omap2/wd_timer.c b/arch/arm/mach-omap2/wd_timer.c
new file mode 100644
index 000..06c256d
--- /dev/null
+++ b/arch/arm/mach-omap2/wd_timer.c
@@ -0,0 +1,68 @@
+/*
+ * OMAP2+ MPU WD_TIMER-specific code
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+#include linux/err.h
+
+#include plat/omap_hwmod.h
+
+/*
+ * In order to avoid any assumptions from bootloader regarding WDT
+ * settings, WDT module is reset during init. This enables the watchdog
+ * timer. Hence it is required to disable the watchdog after the WDT reset
+ * during init. Otherwise the system would reboot as per the default
+ * watchdog timer registers settings.
+ */
+#define OMAP_WDT_WPS 0x34
+#define OMAP_WDT_SPR 0x48
+
+
+int omap2_wd_timer_disable(struct omap_hwmod *oh)
+{
+ void __iomem *base;
+
[PATCH 3/3] OMAP: wd_timer: remove old, dead probing code
After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog
probing is handled by files in mach-omap1/ and mach-omap2/, and the
plat-omap/devices.c probing code is no longer used. Remove the dead
code in plat-omap/devices.c.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Charulatha Varadarajan ch...@ti.com
---
arch/arm/plat-omap/devices.c | 38 --
1 files changed, 0 insertions(+), 38 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 6f42a18..f2d6ecc 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -234,44 +234,6 @@ static inline void omap_init_uwire(void) {}
/*-*/
-#ifdefined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-
-static struct resource wdt_resources[] = {
- {
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap_wdt_device = {
- .name = omap_wdt,
- .id = -1,
- .num_resources = ARRAY_SIZE(wdt_resources),
- .resource = wdt_resources,
-};
-
-static void omap_init_wdt(void)
-{
- if (cpu_is_omap16xx())
- wdt_resources[0].start = 0xfffeb000;
- else if (cpu_is_omap2420())
- wdt_resources[0].start = 0x48022000; /* WDT2 */
- else if (cpu_is_omap2430())
- wdt_resources[0].start = 0x49016000; /* WDT2 */
- else if (cpu_is_omap343x())
- wdt_resources[0].start = 0x48314000; /* WDT2 */
- else if (cpu_is_omap44xx())
- wdt_resources[0].start = 0x4a314000;
- else
- return;
-
- wdt_resources[0].end = wdt_resources[0].start + 0x4f;
-
- (void) platform_device_register(omap_wdt_device);
-}
-#else
-static inline void omap_init_wdt(void) {}
-#endif
-
#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
static phys_addr_t omap_dsp_phys_mempool_base;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism
The OMAP watchdog timer IP blocks require a specific set of register
writes to occur before they will be disabled[1], even if the device
clocks appear to be disabled in the CM_*CLKEN registers. In the MPU
watchdog case, failure to execute this reset sequence will eventually
cause the watchdog to reset the OMAP unexpectedly.
Previously, the code to disable this watchdog was manually called from
mach-omap2/devices.c during device initialization. This causes the
watchdog to be unconditionally disabled for a portion of kernel
initialization. This should be controllable by the board-*.c files,
since some system integrators will want full watchdog coverage of
kernel initialization. Also, the watchdog disable code was not
connected to the hwmod shutdown code. This means that calling
omap_hwmod_shutdown() will not, in fact, disable the watchdog, and the
goal of omap_hwmod_shutdown() is to be able to shutdown any on-chip
OMAP device.
To resolve the latter problem, populate the pre_shutdown pointer in
the watchdog timer hwmod classes with a function that executes the
watchdog shutdown sequence. This allows the hwmod code to fully
disable the watchdog.
Then, to allow some board files to support watchdog coverage
throughout kernel initialization, add common code to mach-omap2/io.c
to cause the MPU watchdog to be disabled on boot unless a board file
specifically requests it to remain enabled. Board files can do this
by changing the watchdog timer hwmod's postsetup state between the
omap2_init_common_infrastructure() and omap2_init_common_devices()
function calls.
1. OMAP34xx Multimedia Device Silicon Revision 3.1.x Rev. ZH
[SWPU222H], Section 16.4.3.6, Start/Stop Sequence for WDTs (Using
WDTi.WSPR Register)
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Charulatha Varadarajan ch...@ti.com
---
arch/arm/mach-omap2/devices.c | 15 ---
arch/arm/mach-omap2/io.c | 18 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 --
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 --
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 --
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
arch/arm/mach-omap2/wd_timer.c | 16 +---
7 files changed, 35 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cd6a46a..b5cafd3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -33,7 +33,6 @@
#include mux.h
#include control.h
-#include wd_timer.h
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -952,26 +951,12 @@ static inline void omap_init_vout(void) {}
/*-*/
-static int omap2_disable_wdt(struct omap_hwmod *oh, void *unused)
-{
- return omap2_wd_timer_disable(oh);
-}
-
-static void __init omap_disable_wdt(void)
-{
- if (cpu_class_is_omap2())
- omap_hwmod_for_each_by_class(wd_timer,
-omap2_disable_wdt, NULL);
- return;
-}
-
static int __init omap2_init_devices(void)
{
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
- omap_disable_wdt();
omap_hsmmc_reset();
omap_init_audio();
omap_init_camera();
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 39ab1ec..5b4f30e 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -341,6 +341,24 @@ void __init omap2_init_common_infrastructure(void)
#endif
omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state);
+ /*
+* Set the default postsetup state for unusual modules (like
+* MPU WDT).
+*
+* The postsetup_state is not actually used until
+* omap_hwmod_late_init(), so boards that desire full watchdog
+* coverage of kernel initialization can reprogram the
+* postsetup_state between the calls to
+* omap2_init_common_infra() and omap2_init_common_devices().
+*
+* XXX ideally we could detect whether the MPU WDT was currently
+* enabled here and make this conditional
+*/
+ postsetup_state = _HWMOD_STATE_DISABLED;
+ omap_hwmod_for_each_by_class(wd_timer,
+_set_hwmod_postsetup_state,
+postsetup_state);
+
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..9a5f0d7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++
Re: [PATCH 0/3] OMAP: wd_timer: update integration code to use new hwmod changes
Paul, Thanks for the series. On Tue, Nov 16, 2010 at 15:55, Paul Walmsley p...@pwsan.com wrote: Update the OMAP watchdog timer integration code to take advantage of the new hwmod upgrades added by the OMAP2+: hwmod core upgrades for 2.6.38: first set series, posted previously. So that series needs to be applied before these patches. Charu, it would be great if you could take a look at these. It looks fine for me. -V Charulatha Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. - Paul --- wdt_2.6.38 text data bss dec hex filename 5709076 470560 5608992 11788628 b3e154 vmlinux.omap2plus_defconfig.orig 5708892 470560 5608992 11788444 b3e09c vmlinux.omap2plus_defconfig.patched Paul Walmsley (3): OMAP2+: wd_timer: separate watchdog disable code from the rest of mach-omap2/devices.c OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism OMAP: wd_timer: remove old, dead probing code arch/arm/mach-omap2/Makefile | 2 - arch/arm/mach-omap2/devices.c | 64 +--- arch/arm/mach-omap2/io.c | 18 arch/arm/mach-omap2/omap_hwmod_2420_data.c | 6 ++- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 6 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 6 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 ++- arch/arm/mach-omap2/wd_timer.c | 54 arch/arm/mach-omap2/wd_timer.h | 17 +++ arch/arm/plat-omap/devices.c | 38 - 10 files changed, 108 insertions(+), 109 deletions(-) create mode 100644 arch/arm/mach-omap2/wd_timer.c create mode 100644 arch/arm/mach-omap2/wd_timer.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
Re: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
On Mon, 2010-11-08 at 13:24 +0100, ext Archit Taneja wrote:
From: Sumit Semwal sumit.sem...@ti.com
A new member 'channel' is introduced in omap_dss_device structure to determine
which channel the panel uses. The dispc functions used by interface drivers
(dsi, sdi etc) will use this member to differentiate between the 2 channels.
The following dispc functions are changed to incorporate channel as an
argument:
-dispc_enable_fifohandcheck()
-dispc_set_lcd_size()
-dispc_set_parallel_interface_mode()
-dispc_set_tft_data_lines()
-dispc_set_lcd_display_type()
-dispc_set_lcd_timings()
The calls to these functions from the interface drivers have been changed to
incorporate the new channel argument.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |1 +
drivers/video/omap2/dss/dispc.c | 49
-
drivers/video/omap2/dss/dpi.c | 11 +++---
drivers/video/omap2/dss/dsi.c | 13 ---
drivers/video/omap2/dss/dss.h | 19 ++-
drivers/video/omap2/dss/rfbi.c| 19 ++-
drivers/video/omap2/dss/sdi.c | 14 +---
7 files changed, 70 insertions(+), 56 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 586944d..3e6eec1 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -434,6 +434,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
Isn't this the same as dssdev-manager-id?
Yes, this channel stuff is a bit confusing, even the enum omap_channel
is badly named (should at least have dss in it). But
omap_overlay_manager should represent the output pipe, so I don't think
there's need for channel field in dss_device.
I think in many places we could even pass omap_overlay_manager pointer
around, instead of omap_channel. However, for low level dispc functions
it's perhaps cleaner to pass the channel ID though.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: Set latency requirements only once for several messages
On Tue, 16 Nov 2010, Samu Onkalo wrote: Ordinary I2C read consist of two messages. First a write operation to tell register address and then read operation to get data. CPU wake up latency is set and removed twice in read case. Set latency requirement before the message processing loop and remove the requirement after the loop to remove latency adjustment operations between the messages. Signed-off-by: Samu Onkalo samu.p.onk...@nokia.com Acked-by: Paul Walmsley p...@pwsan.com - 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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon n...@ti.com wrote: + /* + * Allow multiple calls, but initialize only if not already initalized Minor: s/initalized/initialized/. + * even if the previous call failed, coz, no reason we'd succeed again + */ + if (omap_table_init) + return 0; + omap_table_init = 1; Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1). Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi,
Tomi Valkeinen wrote:
Hi,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 586944d..3e6eec1 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -434,6 +434,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
Isn't this the same as dssdev-manager-id?
Yes, this channel stuff is a bit confusing, even the enum omap_channel
is badly named (should at least have dss in it). But
omap_overlay_manager should represent the output pipe, so I
don't think there's need for channel field in dss_device.
The panel somehow needs to tell which manager it is connected to. We went with
with the way of declaring a new member 'channel' and setting that parameter up
in the
board file.
The current way to relate the manager and device is done by checking the
dssdev-type
in dss_recheck_connections() and then calling set_device()
This is not sufficient any more since two of the managers can support similar
types of
displays.
So in the channel approach the following happens:
-mgr-id's are initialized at bootup.
-devices and managers are connected using 'channel'.
-mgr-id automatically becomes equal to channel.
Can we set something like dssdev-manager-id in the board file itself?
Archit
I think in many places we could even pass
omap_overlay_manager pointer around, instead of omap_channel.
However, for low level dispc functions it's perhaps cleaner
to pass the channel ID though.
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
[RFC] OMAP: Serial: Define register access modes in LCR
From: Andrei Emeltchenko andrei.emeltche...@nokia.com
Access to some registers depends on register access mode
Three different modes are available for OMAP (at least)
* Operational mode LCR_REG[7] = 0x0
* Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF
* Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF
Define access modes and remove redefinitions and magic numbers
in serial drivers (and later in bluetooth driver).
Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
---
arch/arm/mach-omap2/serial.c | 12
arch/arm/plat-omap/include/plat/omap-serial.h |9 --
drivers/serial/8250.c | 26 +-
drivers/serial/omap-serial.c | 34
include/linux/serial_reg.h|6
5 files changed, 42 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index edd7c99..14c8715 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -218,7 +218,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
return;
lcr = serial_read_reg(uart, UART_LCR);
- serial_write_reg(uart, UART_LCR, 0xBF);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
uart-dll = serial_read_reg(uart, UART_DLL);
uart-dlh = serial_read_reg(uart, UART_DLM);
serial_write_reg(uart, UART_LCR, lcr);
@@ -226,7 +226,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
uart-sysc = serial_read_reg(uart, UART_OMAP_SYSC);
uart-scr = serial_read_reg(uart, UART_OMAP_SCR);
uart-wer = serial_read_reg(uart, UART_OMAP_WER);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
uart-mcr = serial_read_reg(uart, UART_MCR);
serial_write_reg(uart, UART_LCR, lcr);
@@ -250,19 +250,19 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
else
serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
efr = serial_read_reg(uart, UART_EFR);
serial_write_reg(uart, UART_EFR, UART_EFR_ECB);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, 0x0);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_DLL, uart-dll);
serial_write_reg(uart, UART_DLM, uart-dlh);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, uart-ier);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
serial_write_reg(uart, UART_MCR, uart-mcr);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_EFR, efr);
serial_write_reg(uart, UART_LCR, UART_LCR_WLEN8);
serial_write_reg(uart, UART_OMAP_SCR, uart-scr);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 6a17880..b3e0bad 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -33,15 +33,6 @@
#define OMAP_MODE13X_SPEED 230400
-/*
- * LCR = 0XBF: Switch to Configuration Mode B.
- * In configuration mode b allow access
- * to EFR,DLL,DLH.
- * Reference OMAP TRM Chapter 17
- * Section: 1.4.3 Mode Selection
- */
-#define OMAP_UART_LCR_CONF_MDB 0XBF
-
/* WER = 0x7F
* Enable module level wakeup in WER reg
*/
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 4d8e14b..aaf9907 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -653,13 +653,13 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
{
if (p-capabilities UART_CAP_SLEEP) {
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_outp(p, UART_EFR, UART_EFR_ECB);
serial_outp(p, UART_LCR, 0);
}
serial_outp(p, UART_IER, sleep ? UART_IERX_SLEEP : 0);
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_outp(p, UART_EFR, 0);
serial_outp(p, UART_LCR, 0);
}
@@ -752,7 +752,7 @@ static int size_fifo(struct uart_8250_port *up)
serial_outp(up,
[RFC] OMAP: Serial: Define register access modes in LCR
From: Andrei Emeltchenko andrei.emeltche...@nokia.com
Access to some registers depends on register access mode
Three different modes are available for OMAP (at least)
* Operational mode LCR_REG[7] = 0x0
* Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF
* Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF
Define access modes and remove redefinitions and magic numbers
in serial drivers (and later in bluetooth driver).
Signed-off-by: Andrei Emeltchenko andrei.emeltche...@nokia.com
---
arch/arm/mach-omap2/serial.c | 12
arch/arm/plat-omap/include/plat/omap-serial.h |9 --
drivers/serial/8250.c | 26 +-
drivers/serial/omap-serial.c | 34
include/linux/serial_reg.h|6
5 files changed, 42 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index edd7c99..14c8715 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -218,7 +218,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
return;
lcr = serial_read_reg(uart, UART_LCR);
- serial_write_reg(uart, UART_LCR, 0xBF);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
uart-dll = serial_read_reg(uart, UART_DLL);
uart-dlh = serial_read_reg(uart, UART_DLM);
serial_write_reg(uart, UART_LCR, lcr);
@@ -226,7 +226,7 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
uart-sysc = serial_read_reg(uart, UART_OMAP_SYSC);
uart-scr = serial_read_reg(uart, UART_OMAP_SCR);
uart-wer = serial_read_reg(uart, UART_OMAP_WER);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
uart-mcr = serial_read_reg(uart, UART_MCR);
serial_write_reg(uart, UART_LCR, lcr);
@@ -250,19 +250,19 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
else
serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
efr = serial_read_reg(uart, UART_EFR);
serial_write_reg(uart, UART_EFR, UART_EFR_ECB);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, 0x0);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_DLL, uart-dll);
serial_write_reg(uart, UART_DLM, uart-dlh);
serial_write_reg(uart, UART_LCR, 0x0); /* Operational mode */
serial_write_reg(uart, UART_IER, uart-ier);
- serial_write_reg(uart, UART_LCR, 0x80);
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A);
serial_write_reg(uart, UART_MCR, uart-mcr);
- serial_write_reg(uart, UART_LCR, 0xBF); /* Config B mode */
+ serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B);
serial_write_reg(uart, UART_EFR, efr);
serial_write_reg(uart, UART_LCR, UART_LCR_WLEN8);
serial_write_reg(uart, UART_OMAP_SCR, uart-scr);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 6a17880..b3e0bad 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -33,15 +33,6 @@
#define OMAP_MODE13X_SPEED 230400
-/*
- * LCR = 0XBF: Switch to Configuration Mode B.
- * In configuration mode b allow access
- * to EFR,DLL,DLH.
- * Reference OMAP TRM Chapter 17
- * Section: 1.4.3 Mode Selection
- */
-#define OMAP_UART_LCR_CONF_MDB 0XBF
-
/* WER = 0x7F
* Enable module level wakeup in WER reg
*/
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 4d8e14b..aaf9907 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -653,13 +653,13 @@ static void serial8250_set_sleep(struct uart_8250_port
*p, int sleep)
{
if (p-capabilities UART_CAP_SLEEP) {
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_outp(p, UART_EFR, UART_EFR_ECB);
serial_outp(p, UART_LCR, 0);
}
serial_outp(p, UART_IER, sleep ? UART_IERX_SLEEP : 0);
if (p-capabilities UART_CAP_EFR) {
- serial_outp(p, UART_LCR, 0xBF);
+ serial_outp(p, UART_LCR, UART_LCR_CONF_MODE_B);
serial_outp(p, UART_EFR, 0);
serial_outp(p, UART_LCR, 0);
}
@@ -752,7 +752,7 @@ static int size_fifo(struct uart_8250_port *up)
serial_outp(up,
[PATCH v2] OMAP: DSS2: OMAPFB: Add null pointer check
A null pointer check added. And using kstrdup()
instead of kmalloc() strcpy()
Signed-off-by: Samreen samr...@ti.com
---
Version2:
- Using kstrdup() instead of kmalloc() strcpy()
- Using ENOMEM as error code instead of EINVAL
- Subject changed appropriately
The link to v1 of patch is:
https://patchwork.kernel.org/patch/319642/
drivers/video/omap2/omapfb/omapfb-main.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 6a704f1..4fdab8e 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2132,8 +2132,9 @@ static int omapfb_parse_def_modes(struct omapfb2_device
*fbdev)
char *str, *options, *this_opt;
int r = 0;
- str = kmalloc(strlen(def_mode) + 1, GFP_KERNEL);
- strcpy(str, def_mode);
+ str = kstrdup(def_mode, GFP_KERNEL);
+ if (!str)
+ return -ENOMEM;
options = str;
while (!r (this_opt = strsep(options, ,)) != NULL) {
--
1.5.6.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
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni wrote, on 11/16/2010 05:21 AM: Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menonn...@ti.com wrote: + /* +* Allow multiple calls, but initialize only if not already initalized Minor: s/initalized/initialized/. aah thanks :) +* even if the previous call failed, coz, no reason we'd succeed again +*/ + if (omap_table_init) + return 0; + omap_table_init = 1; Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1). Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone - it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid. btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that. -- Regards, Nishanth Menon -- 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
- Original Message -
From: Grant Erickson maratho...@gmail.com
To: linux-omap@vger.kernel.org
Cc: Tony Lindgren t...@atomide.com
Sent: Monday, November 15, 2010 12:58 AM
Subject: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode
Timers
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
Generally PWMs are supported on PMIC chip. Is this driver intended for use
when OMAP is used standalone.
Boards can register such devices using platform data such as in the
following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
Since only specific GPTs can be configured for PWM, can some check
we added in probe function.
.polarity = 1 // Active-high
};
static struct platform_device pwm_device = {
.name = omap-pwm,
.id = 0,
.dev= {
.platform_data = pwm_config
}
};
Signed-off-by: Grant Erickson maratho...@gmail.com
---
arch/arm/plat-omap/Kconfig|9 +
arch/arm/plat-omap/Makefile |2 +
arch/arm/plat-omap/include/plat/pwm.h | 29 ++
arch/arm/plat-omap/pwm.c | 450
+
Can the above file be part of mach-omap2, since comment say its
specifically
for OMAP2/3 or will this work on OMAP1 also.
4 files changed, 490 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 92c5bb7..4797b0e 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -164,6 +164,15 @@ config OMAP_DM_TIMER
help
Select this option if you want to use OMAP Dual-Mode timers.
+config HAVE_PWM
+ bool Use PWM timers
+ depends on OMAP_DM_TIMER
+ help
+ Select this option if you want to be able to request and use
+ one or more of the OMAP dual-mode timers as a generic PWM device
+ compatible with other generic PWM drivers such as the backlight
or
+ beeper driver.
+
config OMAP_SERIAL_WAKE
bool Enable wake-up events for serial ports
depends on ARCH_OMAP1 OMAP_MUX
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..9e5347b 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -32,3 +32,5 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
+
+obj-$(CONFIG_HAVE_PWM) += pwm.o
diff --git a/arch/arm/plat-omap/include/plat/pwm.h
b/arch/arm/plat-omap/include/plat/pwm.h
new file mode 100644
index 000..04030cd
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/pwm.h
@@ -0,0 +1,29 @@
+/*
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.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.
+ *
+ *Description:
+ * This file is defines platform-specific configuration data for
+ * the OMAP generic PWM platform driver.
+ */
+
+#ifndef _OMAP2_PWM_H
+#define _OMAP2_PWM_H
+
+/**
+ * struct omap2_pwm_platform_config - OMAP platform-specific data for
PWMs
+ * @timer_id: the OMAP dual-mode timer ID.
+ * @polarity: the polarity (active-high or -low) of the PWM.
+ *
+ * This identifies the OMAP dual-mode timer (dmtimer) that will be bound
+ * to the PWM.
+ */
+struct omap2_pwm_platform_config {
+ int timer_id;
+ bool polarity;
+};
+
+#endif /* _OMAP2_PWM_H */
diff --git a/arch/arm/plat-omap/pwm.c b/arch/arm/plat-omap/pwm.c
new file mode 100644
index 000..c6d103d
--- /dev/null
+++ b/arch/arm/plat-omap/pwm.c
@@ -0,0 +1,450 @@
+/*
+ *Copyright (c) 2010 Grant Erickson maratho...@gmail.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.
+ *
+ *Description:
+ * This file is the core OMAP2/3 support for the generic, Linux
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pwm.h
+#include mach/hardware.h
+#include plat/dmtimer.h
+#include plat/pwm.h
+
+/* Preprocessor Definitions */
+
+#undef OMAP_PWM_DEBUG
+
+#if defined(OMAP_PWM_DEBUG)
+#define DBG(args...) \
+ do { \
+ pr_info(args); \
+ } while (0)
+#define DEV_DBG(dev, args...) \
+ do { \
+ dev_info(dev, args); \
+ } while (0)
+#else
+#define DBG(args...) \
+ do { } while (0)
+#define DEV_DBG(dev, args...) \
+ do { } while (0)
+#endif /* defined(OMAP_PWM_DEBUG) */
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+/*
Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
On Sun, Nov 14, 2010 at 01:28:49PM -0600, Grant Erickson wrote: +MODULE_LICENSE(GPLv2); module license should be GPL v2 just read the comment above MODULE_LICENSE definition: /* * The following license idents are currently accepted as indicating free * software modules * * GPL [GNU Public License v2 or later] * GPL v2 [GNU Public License v2] * GPL and additional rights [GNU Public License v2 rights and more] * Dual BSD/GPL[GNU Public License v2 * or BSD license choice] * Dual MIT/GPL[GNU Public License v2 * or MIT license choice] * Dual MPL/GPL[GNU Public License v2 * or Mozilla license choice] * * The following other idents are available * * Proprietary [Non free products] * * There are dual licensed components, but when running with Linux it is the * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL * is a GPL combined work. * * This exists for several reasons * 1. So modinfo can show license info for users wanting to vet their setup * is free * 2. So the community can ignore bug reports including proprietary modules * 3. So vendors can do likewise based on their own policies */ -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello, On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menon n...@ti.com wrote: Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1). Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone - it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid. Ah, right, I didn't catch that omapX_init_opp() could be called first from the board init function, and then later on as a device_initcall() callback. But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to omapX_init_opp() would be needed as a device_initcall() callback. Or, add a mechanism that allows the board file to register its customizations, that are later taken into account by the omapX_init_opp() function. Maybe it's just a matter of personal taste, but I really don't like this kind of let's call this function once, do some stuff, then call it again, since it'll know that it shouldn't do anything. btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that. I don't see why replacing: + if (omap_table_init) + return 0; + omap_table_init = 1; by BUG_ON(omap_table_init == 1); omap_table_init = 1; would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()). Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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] OMAP: wd_timer: remove old, dead probing code
Hello. On 16-11-2010 13:25, Paul Walmsley wrote: After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog Linus has asked to also specify the commit summary in parens... probing is handled by files in mach-omap1/ and mach-omap2/, and the plat-omap/devices.c probing code is no longer used. Remove the dead code in plat-omap/devices.c. Signed-off-by: Paul Walmsleyp...@pwsan.com Cc: Charulatha Varadarajanch...@ti.com WBR, Sergei -- 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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni wrote, on 11/16/2010 06:42 AM: Hello, On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menonn...@ti.com wrote: Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice, I'd rather not have this, or turn this into a BUG_ON(omap_table_init == 1). Yes, it is needed. The intent here is different. See the documentation that I put along with this patch - At times, board files may need to do customization to opps - like enable 1GHz on that platform alone - it can do it *only if* the defaults are registered, following which it can call opp_enable. when device_initcall follows this at a later point, it is still valid. Ah, right, I didn't catch that omapX_init_opp() could be called first from the board init function, and then later on as a device_initcall() callback. But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to omapX_init_opp() would be needed as a device_initcall() callback. Or, add a mechanism that allows the board file to register its customizations, that are later taken into account by the omapX_init_opp() function. Maybe it's just a matter of personal taste, but I really don't like this kind of let's call this function once, do some stuff, then call it again, since it'll know that it shouldn't do anything., I feel you may have misunderstood the code, we DONOT oblige all boards to *have* to call omapX_init_opp. It is a device_initcall - so for the boards that dont call it, device_initcall will trigger and initialzie it. the hooks for the customization of the OPPs is in OPP layer itself. the need we satisfy is this: if you need to support two sets of boards: a) boards that are happy with the defaults - most of the boards - dont do anything in the board file. (device_init_call with auto register the defaults) b) boards that need customization - these guys need to call omapX_init_opp(to register the defaults) before customizing the defaults. Does this explain the code and reason for the logic? if you do have a better mechanism, lets know. btw, BUG_ON is a strict NO NO for me here - if I dont have OPP table, ok fine, system can still survive without cpufreq, no need to stop system operations because of that. I don't see why replacing: + if (omap_table_init) + return 0; + omap_table_init = 1; by BUG_ON(omap_table_init == 1); omap_table_init = 1; would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()). HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code. -- Regards, Nishanth Menon -- 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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Hello, On Tue, 16 Nov 2010 07:10:36 -0600 Nishanth Menon n...@ti.com wrote: I feel you may have misunderstood the code, we DONOT oblige all boards to *have* to call omapX_init_opp. It is a device_initcall - so for the boards that dont call it, device_initcall will trigger and initialzie it. the hooks for the customization of the OPPs is in OPP layer itself. This is exactly what I have understood. the need we satisfy is this: if you need to support two sets of boards: a) boards that are happy with the defaults - most of the boards - dont do anything in the board file. (device_init_call with auto register the defaults) b) boards that need customization - these guys need to call omapX_init_opp(to register the defaults) before customizing the defaults. Does this explain the code and reason for the logic? if you do have a better mechanism, lets know. Yes, it explains the code and reason for the logic, but still doesn't make it pretty :-) would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()). HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code. In the current design, yes, there are indeed valid reasons for reentry into the omapX_init_opp() function, and that's exactly the point I'm critizicing here. Regards! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
On Tue, 2010-11-16 at 12:22 +0100, ext Taneja, Archit wrote:
Hi,
Tomi Valkeinen wrote:
Hi,
[snip]
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 586944d..3e6eec1 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -434,6 +434,7 @@ struct omap_dss_device {
struct omap_overlay_manager *manager;
enum omap_dss_display_state state;
+ enum omap_channel channel;
Isn't this the same as dssdev-manager-id?
Yes, this channel stuff is a bit confusing, even the enum omap_channel
is badly named (should at least have dss in it). But
omap_overlay_manager should represent the output pipe, so I
don't think there's need for channel field in dss_device.
The panel somehow needs to tell which manager it is connected to. We went with
with the way of declaring a new member 'channel' and setting that parameter
up in the
board file.
The current way to relate the manager and device is done by checking the
dssdev-type
in dss_recheck_connections() and then calling set_device()
This is not sufficient any more since two of the managers can support similar
types of
displays.
So in the channel approach the following happens:
-mgr-id's are initialized at bootup.
-devices and managers are connected using 'channel'.
-mgr-id automatically becomes equal to channel.
Can we set something like dssdev-manager-id in the board file itself?
Right, now I see.
The dss_recheck_connections() felt like a hack when I wrote it =).
Clearly we need some way to define in the board file which panel
connects to which manager.
Perhaps move the channel-field up, just below enum omap_display_type
type. The lines in the beginning of omap_dss_device are things which
define the interface etc, and later there are miscallaneous dynamic
things. And this belongs to the former.
Now, if we have the channel defined in this way in the omap_dss_device,
I'm wondering if:
1) the manager pointer is needed at all, as the channel tells which
manager it is?
2) if we keep the manager pointer (as a helper shortcut), should the
code use generally use dssdev-channel or dssdev-manager-id?
3) having this channel field requires a change to every board file,
because the channel has to be defined?
And answering to myself, I guess the manager pointer is needed, because
DSS2 supports (at least in theory) multiple panels in the same interface
(not at the same time, of course). This means that we could have to
panels, with the same interface and channel, but only one would be in
use. So the one in use should have manager pointing to the correct
manager, and the other would have manager NULL.
And thus perhaps using dssdev-channel only for connecting the right
manager to right panel, and using dssdev-manager-id for other uses
would be the best? The values would of course be the same, but at least
we'd get a crash if somehow an unconnected display is being used for
configuration.
Does this make sense?
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, November 06, 2010 2:43 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc * Ghorai, Sukumar s-gho...@ti.com [101028 07:02]: Tony, -Original Message- From: Ghorai, Sukumar Sent: Wednesday, September 29, 2010 12:08 PM To: 'Tony Lindgren' Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux- arm- ker...@lists.infradead.org Subject: RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc [..snip..] diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach- omap2/board-3430sdp.c index 67b95b5..549cd62 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } ... You can avoid adding gpmc_init() by making it a subsys_initcall(). Just make sure you return early from it with if (!cpu_class_is_omap2()). [Ghorai] will do [Ghorai] I was trying this and no success, as nand_init() get called before subsys_initcall(gpmc_init); 126 MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board) .. 130 .init_irq = omap_zoom_init_irq, 131 .init_machine = omap_zoom_init, .. Step-(n): kernel_init() - customize_machine() - omap_zoom_init() - gpmc_nand_init() - which call gpmc functions, that's crashing, as gpmc is not initialized. Step-(n+1): Followed by subsys_initcall(gpmc_init) So I will incorporate the other input and will re-submit. [..snip..] I don't see why you could not make gpmc_nand_init happen later? Also, some of these calls can be moved to omap2_init_common_hw()? [Ghorai] is it that gpmc_nand_init() better to call inside omap2_init_common_hw()? 27 files used the omap2_init_common_hw(); including omap4, and 15 files used the gpmc_nand_init directly or via board_nand_init() Just thinking how to put gpmc_nand_init() inside omap2_init_common_hw(), when board may not have the nand. -- 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] OMAP: DSS2: Add generic DPI panel display driver
Hi,
On Tue, 2010-11-16 at 05:17 +0100, ext Bryan Wu wrote:
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 +++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 333
4 files changed, 379 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.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.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+tristate Generic DPI Panel
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..c3fff9e
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,333 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.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.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/panel-generic-dpi.h
+
+struct panel_config {
+ struct omap_video_timings timings;
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni had written, on 11/16/2010 06:42 AM, the following: But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to I knew I had discussed this before! Apologies, I should have dug this thread up earlier in the discussion. my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here: http://marc.info/?l=linux-omapm=127507237109393w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap
This is in preparation of splitting the powerdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
The platform-independent code would reside in plat-omap/powerdomain.c
and the platform-specific code will resides in
mach-omap2/powerdomain-.c files.
Some of the hacks to include header files are done to make sure the
patch compiles and works fine. These hacks will be removed in the
subsequent patches.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/plat-omap/Makefile |6 +++---
arch/arm/{mach-omap2 = plat-omap}/powerdomain.c | 14 +++---
3 files changed, 11 insertions(+), 11 deletions(-)
rename arch/arm/{mach-omap2 = plat-omap}/powerdomain.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..4bfadc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -9,7 +9,7 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o
timer-gp.o pm.o \
omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
omap_hwmod_common_data.o
-prcm-common= prcm.o powerdomain.o
+prcm-common= prcm.o
clock-common = clock.o clock_common_data.o \
clockdomain.o clkt_dpll.o \
clkt_clksel.o
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index a4a1285..424a9ae 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -13,9 +13,9 @@ obj- :=
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# omap_device support (OMAP2+ only at the moment)
-obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
-obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
+obj-$(CONFIG_ARCH_OMAP2) += omap_device.o powerdomain.o
+obj-$(CONFIG_ARCH_OMAP3) += omap_device.o powerdomain.o
+obj-$(CONFIG_ARCH_OMAP4) += omap_device.o powerdomain.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
obj-$(CONFIG_OMAP_IOMMU) += iommu.o iovmm.o
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/plat-omap/powerdomain.c
similarity index 99%
rename from arch/arm/mach-omap2/powerdomain.c
rename to arch/arm/plat-omap/powerdomain.c
index 6527ec3..9204799 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -26,19 +26,19 @@
#include asm/atomic.h
-#include cm.h
-#include cm-regbits-34xx.h
-#include cm-regbits-44xx.h
-#include prm.h
-#include prm-regbits-34xx.h
-#include prm-regbits-44xx.h
+#include ../mach-omap2/cm.h
+#include ../mach-omap2/cm-regbits-34xx.h
+#include ../mach-omap2/cm-regbits-44xx.h
+#include ../mach-omap2/prm.h
+#include ../mach-omap2/prm-regbits-34xx.h
+#include ../mach-omap2/prm-regbits-44xx.h
#include plat/cpu.h
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/prcm.h
-#include pm.h
+#include ../mach-omap2/pm.h
enum {
PWRDM_STATE_NOW = 0,
--
1.7.0.4
--
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 6/6] OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4430 ES2 has additional bitfields in PWRSTST register which help
identify the previous power state entered by the powerdomain.
Add pwrdm_clear_all_prev_pwrst api to support this.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains44xx.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx.c
b/arch/arm/mach-omap2/powerdomains44xx.c
index 79be2cd..0414e6a 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.c
+++ b/arch/arm/mach-omap2/powerdomains44xx.c
@@ -45,6 +45,14 @@ static int omap4_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
OMAP4430_LASTPOWERSTATEENTERED_MASK);
}
+static int omap4_pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm)
+{
+ prm_rmw_mod_reg_bits(OMAP4430_LASTPOWERSTATEENTERED_MASK,
+ 0x3 OMAP4430_LASTPOWERSTATEENTERED_SHIFT,
+ pwrdm-prcm_offs, OMAP4_PM_PWSTST);
+ return 0;
+}
+
static int omap4_pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm)
{
prm_rmw_mod_reg_bits(OMAP4430_LOWPOWERSTATECHANGE_MASK,
@@ -154,6 +162,7 @@ struct pwrdm_functions omap4_pwrdm_functions = {
.pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = omap4_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap4_pwrdm_read_prev_pwrst,
+ .pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_lowpwrstchange = omap4_pwrdm_set_lowpwrstchange,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
--
1.7.0.4
--
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 4/6] OMAP: powerdomain: Arch specific funcs for logic control
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_logic_retst
.pwrdm_read_logic_pwrst
.pwrdm_read_prev_logic_pwrst
.pwrdm_read_logic_retst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomains2xxx.c | 34 +
arch/arm/mach-omap2/powerdomains44xx.c | 26
arch/arm/plat-omap/powerdomain.c | 51 ++--
3 files changed, 82 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains2xxx.c
b/arch/arm/mach-omap2/powerdomains2xxx.c
index dfeb8af..779529d 100644
--- a/arch/arm/mach-omap2/powerdomains2xxx.c
+++ b/arch/arm/mach-omap2/powerdomains2xxx.c
@@ -45,9 +45,43 @@ static int omap2_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
OMAP3430_LASTPOWERSTATEENTERED_MASK);
}
+static int omap2_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ u32 v;
+
+ v = pwrst __ffs(OMAP3430_LOGICL1CACHERETSTATE_MASK);
+ prm_rmw_mod_reg_bits(OMAP3430_LOGICL1CACHERETSTATE_MASK, v,
+ pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL);
+
+ return 0;
+}
+
+static int omap2_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP2_PM_PWSTST,
+ OMAP3430_LOGICSTATEST_MASK);
+}
+
+
+static int omap2_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP3430_PM_PREPWSTST,
+ OMAP3430_LASTLOGICSTATEENTERED_MASK);
+}
+
+static int omap2_pwrdm_read_logic_retst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL,
+ OMAP3430_LOGICSTATEST_MASK);
+}
+
struct pwrdm_functions omap2_pwrdm_functions = {
.pwrdm_set_next_pwrst = omap2_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = omap2_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = omap2_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap2_pwrdm_read_prev_pwrst,
+ .pwrdm_set_logic_retst = omap2_pwrdm_set_logic_retst,
+ .pwrdm_read_logic_pwrst = omap2_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap2_pwrdm_read_prev_logic_pwrst,
+ .pwrdm_read_logic_retst = omap2_pwrdm_read_logic_retst,
};
diff --git a/arch/arm/mach-omap2/powerdomains44xx.c
b/arch/arm/mach-omap2/powerdomains44xx.c
index b3aaf9b..016a425 100644
--- a/arch/arm/mach-omap2/powerdomains44xx.c
+++ b/arch/arm/mach-omap2/powerdomains44xx.c
@@ -45,9 +45,35 @@ static int omap4_pwrdm_read_prev_pwrst(struct powerdomain
*pwrdm)
OMAP4430_LASTPOWERSTATEENTERED_MASK);
}
+static int omap4_pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ u32 v;
+
+ v = pwrst __ffs(OMAP4430_LOGICRETSTATE_MASK);
+ prm_rmw_mod_reg_bits(OMAP4430_LOGICRETSTATE_MASK, v,
+ pwrdm-prcm_offs, OMAP4_PM_PWSTCTRL);
+
+ return 0;
+}
+
+static int omap4_pwrdm_read_logic_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP4_PM_PWSTST,
+ OMAP4430_LOGICSTATEST_MASK);
+}
+
+static int omap4_pwrdm_read_logic_retst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP4_PM_PWSTCTRL,
+ OMAP4430_LOGICRETSTATE_MASK);
+}
+
struct pwrdm_functions omap4_pwrdm_functions = {
.pwrdm_set_next_pwrst = omap4_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = omap4_pwrdm_read_next_pwrst,
.pwrdm_read_pwrst = omap4_pwrdm_read_pwrst,
.pwrdm_read_prev_pwrst = omap4_pwrdm_read_prev_pwrst,
+ .pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
+ .pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
};
diff --git a/arch/arm/plat-omap/powerdomain.c b/arch/arm/plat-omap/powerdomain.c
index 73d6dad..9177fbb 100644
--- a/arch/arm/plat-omap/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -531,7 +531,7 @@ int pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8 pwrst)
{
- u32 v;
+ int ret = -EINVAL;
if (!pwrdm)
return -EINVAL;
@@ -542,17 +542,10 @@ int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8
pwrst)
pr_debug(powerdomain: setting next logic powerstate for %s to %0x\n,
pwrdm-name, pwrst);
- /*
-* The register bit names below may not correspond to the
-* actual names of the bits in each powerdomain's register,
-
[PATCH 5/6] OMAP: powerdomain: Arch specific funcs for mem control
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_mem_onst
.pwrdm_set_mem_retst
.pwrdm_read_mem_pwrst
.pwrdm_read_prev_mem_pwrst
.pwrdm_read_mem_retst
.pwrdm_clear_all_prev_pwrst
.pwrdm_enable_hdwr_sar
.pwrdm_disable_hdwr_sar
.pwrdm_wait_transition
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/powerdomains.c | 114
arch/arm/mach-omap2/powerdomains.h |5 +
arch/arm/mach-omap2/powerdomains2xxx.c | 129 ++
arch/arm/mach-omap2/powerdomains44xx.c | 87 +
arch/arm/plat-omap/powerdomain.c | 306 ++--
6 files changed, 391 insertions(+), 252 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomains.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5f843fc..87a73b7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \
-common.o
+common.o powerdomains.o
omap-2-3-common= irq.o sdrc.o prm2xxx_3xxx.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/powerdomains.c
b/arch/arm/mach-omap2/powerdomains.c
new file mode 100644
index 000..876bebe
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains.c
@@ -0,0 +1,114 @@
+/*
+ * linux/arch/arm/mach-omap2/powerdomains.c
+ * Contains common powerdomain framework functions
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * Derived from mach-omap2/powerdomain.c written by Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/errno.h
+#include linux/kernel.h
+#include pm.h
+#include cm.h
+#include cm-regbits-34xx.h
+#include cm-regbits-44xx.h
+#include prm-regbits-34xx.h
+#include prm-regbits-44xx.h
+
+/*
+ * OMAP3 and OMAP4 specific register bit initialisations
+ * Notice that the names here are not according to each power
+ * domain but the bit mapping used applies to all of them
+ */
+/* OMAP3 and OMAP4 Memory Onstate Masks (common across all power domains) */
+#define OMAP_MEM0_ONSTATE_MASK OMAP3430_SHAREDL1CACHEFLATONSTATE_MASK
+#define OMAP_MEM1_ONSTATE_MASK OMAP3430_L1FLATMEMONSTATE_MASK
+#define OMAP_MEM2_ONSTATE_MASK OMAP3430_SHAREDL2CACHEFLATONSTATE_MASK
+#define OMAP_MEM3_ONSTATE_MASK OMAP3430_L2FLATMEMONSTATE_MASK
+#define OMAP_MEM4_ONSTATE_MASK OMAP4430_OCP_NRET_BANK_ONSTATE_MASK
+
+/* OMAP3 and OMAP4 Memory Retstate Masks (common across all power domains) */
+#define OMAP_MEM0_RETSTATE_MASK OMAP3430_SHAREDL1CACHEFLATRETSTATE_MASK
+#define OMAP_MEM1_RETSTATE_MASK OMAP3430_L1FLATMEMRETSTATE_MASK
+#define OMAP_MEM2_RETSTATE_MASK OMAP3430_SHAREDL2CACHEFLATRETSTATE_MASK
+#define OMAP_MEM3_RETSTATE_MASK OMAP3430_L2FLATMEMRETSTATE_MASK
+#define OMAP_MEM4_RETSTATE_MASK OMAP4430_OCP_NRET_BANK_RETSTATE_MASK
+
+/* OMAP3 and OMAP4 Memory Status bits */
+#define OMAP_MEM0_STATEST_MASK OMAP3430_SHAREDL1CACHEFLATSTATEST_MASK
+#define OMAP_MEM1_STATEST_MASK OMAP3430_L1FLATMEMSTATEST_MASK
+#define OMAP_MEM2_STATEST_MASK OMAP3430_SHAREDL2CACHEFLATSTATEST_MASK
+#define OMAP_MEM3_STATEST_MASK OMAP3430_L2FLATMEMSTATEST_MASK
+#define OMAP_MEM4_STATEST_MASK OMAP4430_OCP_NRET_BANK_STATEST_MASK
+
+int _get_mem_bank_onstate_mask(u8 bank);
+int _get_mem_bank_retst_mask(u8 bank);
+int _get_mem_bank_stst_mask(u8 bank);
+
+/* Common Internal functions used across OMAP rev's*/
+int _get_mem_bank_onstate_mask(u8 bank)
+{
+ switch (bank) {
+ case 0:
+ return OMAP_MEM0_ONSTATE_MASK;
+ case 1:
+ return OMAP_MEM1_ONSTATE_MASK;
+ case 2:
+ return OMAP_MEM2_ONSTATE_MASK;
+ case 3:
+ return OMAP_MEM3_ONSTATE_MASK;
+ case 4:
+ return OMAP_MEM4_ONSTATE_MASK;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
+ }
+ return 0;
+}
+
+int _get_mem_bank_retst_mask(u8 bank)
+{
+ switch (bank) {
+ case 0:
+ return OMAP_MEM0_RETSTATE_MASK;
+ case 1:
+ return OMAP_MEM1_RETSTATE_MASK;
+ case 2:
+ return OMAP_MEM2_RETSTATE_MASK;
+ case 3:
+ return OMAP_MEM3_RETSTATE_MASK;
+ case 4:
+ return OMAP_MEM4_RETSTATE_MASK;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
+ }
+ return 0;
+}
+
+int _get_mem_bank_stst_mask(u8 bank)
+{
+
[PATCH 0/6] Split powerdomain framework into plat specific/independent
OMAP4 powerdomains have some inherent differences as compared
to OMAP2/3 powerdomains, starting with register offsets being different
to clubbing of multiple controls into one register and in some cases
splitting of control into multiple registers.
There are also new features like lowpowerstatechange bits and features
like HW SAR which are no longer present in the older form.
Supporting all these in the existing powerdomain framework would mean adding
a lot of cpu_is_* checks which makes code unmaintainable going fwd.
Hence this series is an attempt to split the existing powerdomain framework
into platform independent part (which does error checking, usecounting et al)
which can be reused across OMAP's and hook up platform specific functions to
do low level programming which varies across OMAP's.
The series is boot tested on OMAP 2430sdp/3430sdp and 4430sdp platforms.
Additionally on 3430sdp, Retention and OFF support in system suspend is
also validated with a minimal kernel config (omap3_pm_defconfig from
Kevins tree hosted here
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git)
The RFC series of these patches was posted here
http://marc.info/?l=linux-omapm=128524530605407w=2
This series fixes all issues discussed on the RFC series and also has
a few other changes
-1- The below patch is dropped as the dependent patches for this are
still under discussion.
[RFC 6/8] OMAP: PRM: split the prm accessor api funcs for omap2/3 and omap4
http://marc.info/?l=linux-omapm=128524531505429w=2
-2- The below patch is also dropped as there are more than one context
registers to be handled in some powerdomains and hence needs to be
handled differently
[RFC 7/8] omap4: powerdomain: add context_offset field
http://marc.info/?l=linux-omapm=128524531805435w=2
Rajendra Nayak (5):
OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap
OMAP: powerdomain: Infrastructure to put arch specific code
OMAP: powerdomain: Arch specific funcs for state control
OMAP: powerdomain: Arch specific funcs for logic control
OMAP: powerdomain: Arch specific funcs for mem control
Santosh Shilimkar (1):
OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst
arch/arm/mach-omap2/Makefile |9 +-
arch/arm/mach-omap2/io.c |5 +-
arch/arm/mach-omap2/powerdomains.c | 114 ++
arch/arm/mach-omap2/powerdomains.h | 13 +
arch/arm/mach-omap2/powerdomains2xxx.c | 215
arch/arm/mach-omap2/powerdomains44xx.c | 175 ++
arch/arm/plat-omap/Makefile |6 +-
arch/arm/plat-omap/include/plat/powerdomain.h| 22 ++-
arch/arm/{mach-omap2 = plat-omap}/powerdomain.c | 400 ++
9 files changed, 660 insertions(+), 299 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomains.c
create mode 100644 arch/arm/mach-omap2/powerdomains2xxx.c
create mode 100644 arch/arm/mach-omap2/powerdomains44xx.c
rename arch/arm/{mach-omap2 = plat-omap}/powerdomain.c (70%)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] OMAP: powerdomain: Infrastructure to put arch specific code
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/include/plat/powerdomain.h | 22 +-
arch/arm/plat-omap/powerdomain.c | 10 --
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..76c531a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -316,7 +316,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
u8 skip_setup_idle = 0;
- pwrdm_init(powerdomains_omap);
+ pwrdm_init(powerdomains_omap, NULL);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
omap2420_hwmod_init();
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 9ca420d..35e1ef7 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -117,8 +117,28 @@ struct powerdomain {
#endif
};
+struct pwrdm_functions {
+ int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_logic_retst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_set_mem_onst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_set_mem_retst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_read_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_logic_retst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_mem_pwrst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_read_prev_mem_pwrst)(struct powerdomain *pwrdm, u8
bank);
+ int (*pwrdm_read_mem_retst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_clear_all_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_enable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
+ int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
+};
-void pwrdm_init(struct powerdomain **pwrdm_list);
+void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_functions
*custom_funcs);
struct powerdomain *pwrdm_lookup(const char *name);
diff --git a/arch/arm/plat-omap/powerdomain.c b/arch/arm/plat-omap/powerdomain.c
index 9204799..9e2d712 100644
--- a/arch/arm/plat-omap/powerdomain.c
+++ b/arch/arm/plat-omap/powerdomain.c
@@ -80,6 +80,8 @@ static u16 pwrstst_reg_offs;
/* pwrdm_list contains all registered struct powerdomains */
static LIST_HEAD(pwrdm_list);
+static struct pwrdm_functions *arch_pwrdm;
+
/* Private functions */
static struct powerdomain *_pwrdm_lookup(const char *name)
@@ -218,7 +220,7 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
* registered. No return value. XXX pwrdm_list is not really a
* list; it is an array. Rename appropriately.
*/
-void pwrdm_init(struct powerdomain **pwrdm_list)
+void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_functions
*custom_funcs)
{
struct powerdomain **p = NULL;
@@ -234,6 +236,11 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
return;
}
+ if (!custom_funcs)
+ WARN(1, No custom pwrdm functions registered\n);
+ else
+ arch_pwrdm = custom_funcs;
+
if (pwrdm_list) {
for (p = pwrdm_list; *p; p++)
_pwrdm_register(*p);
@@ -1074,4 +1081,3 @@ int pwrdm_post_transition(void)
pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
-
--
1.7.0.4
--
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 3/6] OMAP: powerdomain: Arch specific funcs for state control
Define the following architecture specific funtions for omap2/3/4
.pwrdm_set_next_pwrst
.pwrdm_read_next_pwrst
.pwrdm_read_pwrst
.pwrdm_read_prev_pwrst
Convert the platform-independent framework to call these functions.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Makefile |5 +++
arch/arm/mach-omap2/io.c |5 ++-
arch/arm/mach-omap2/powerdomains.h |8 +
arch/arm/mach-omap2/powerdomains2xxx.c | 53
arch/arm/mach-omap2/powerdomains44xx.c | 53
arch/arm/plat-omap/powerdomain.c | 33 ++--
6 files changed, 146 insertions(+), 11 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomains2xxx.c
create mode 100644 arch/arm/mach-omap2/powerdomains44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4bfadc5..5f843fc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -94,6 +94,11 @@ obj-$(CONFIG_ARCH_OMAP2430) +=
omap_hwmod_2430_data.o
obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += omap_hwmod_44xx_data.o
+#powerdomain framework
+obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx.o
+obj-$(CONFIG_ARCH_OMAP3) += powerdomains2xxx.o
+obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx.o
+
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 76c531a..c68e989 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -316,7 +316,10 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
{
u8 skip_setup_idle = 0;
- pwrdm_init(powerdomains_omap, NULL);
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ pwrdm_init(powerdomains_omap, omap2_pwrdm_functions);
+ else if (cpu_is_omap44xx())
+ pwrdm_init(powerdomains_omap, omap4_pwrdm_functions);
clkdm_init(clockdomains_omap, clkdm_autodeps);
if (cpu_is_omap242x())
omap2420_hwmod_init();
diff --git a/arch/arm/mach-omap2/powerdomains.h
b/arch/arm/mach-omap2/powerdomains.h
index 105cbca..b25b989 100644
--- a/arch/arm/mach-omap2/powerdomains.h
+++ b/arch/arm/mach-omap2/powerdomains.h
@@ -88,8 +88,16 @@ static struct powerdomain wkup_omap2_pwrdm = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
};
+extern struct pwrdm_functions omap2_pwrdm_functions;
+#else
+static struct pwrdm_functions omap2_pwrdm_functions;
#endif
+#ifdef CONFIG_ARCH_OMAP4
+extern struct pwrdm_functions omap4_pwrdm_functions;
+#else
+static struct pwrdm_functions omap4_pwrdm_functions;
+#endif
/* As powerdomains are added or removed above, this list must also be changed
*/
static struct powerdomain *powerdomains_omap[] __initdata = {
diff --git a/arch/arm/mach-omap2/powerdomains2xxx.c
b/arch/arm/mach-omap2/powerdomains2xxx.c
new file mode 100644
index 000..dfeb8af
--- /dev/null
+++ b/arch/arm/mach-omap2/powerdomains2xxx.c
@@ -0,0 +1,53 @@
+/*
+ * OMAP2 and OMAP3 powerdomain control
+ *
+ * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2007-2009 Nokia Corporation
+ *
+ * Derived from mach-omap2/powerdomain.c written by Paul Walmsley
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/io.h
+#include linux/errno.h
+#include linux/delay.h
+#include plat/powerdomain.h
+#include plat/prcm.h
+#include powerdomains.h
+
+static int omap2_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
+{
+ prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
+ (pwrst OMAP_POWERSTATE_SHIFT),
+ pwrdm-prcm_offs, OMAP2_PM_PWSTCTRL);
+ return 0;
+}
+
+static int omap2_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ OMAP2_PM_PWSTCTRL, OMAP_POWERSTATE_MASK);
+}
+
+static int omap2_pwrdm_read_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ OMAP2_PM_PWSTST, OMAP_POWERSTATEST_MASK);
+}
+
+static int omap2_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)
+{
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, OMAP3430_PM_PREPWSTST,
+ OMAP3430_LASTPOWERSTATEENTERED_MASK);
+}
+
+struct pwrdm_functions omap2_pwrdm_functions = {
+ .pwrdm_set_next_pwrst = omap2_pwrdm_set_next_pwrst,
+ .pwrdm_read_next_pwrst = omap2_pwrdm_read_next_pwrst,
+
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here: http://marc.info/?l=linux-omapm=127507237109393w=2 Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni had written, on 11/16/2010 09:50 AM, the following: On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here: http://marc.info/?l=linux-omapm=127507237109393w=2 Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers. Thanks for taking the time to review and the comments. It is always a good idea to evolve to a better solution. If there are no further comments, I will post a v4 later today incorporating comments: a) return error instead of 0 if opp table is already initialized b) change the .h to .c -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OMAP: powerdomain: Arch specific funcs for mem control
Hello,
On Tue, 16 Nov 2010 21:08:05 +0530
Rajendra Nayak rna...@ti.com wrote:
Define the following architecture specific funtions for omap2/3/4
funtions - functions.
+/* Common Internal functions used across OMAP rev's*/
+int _get_mem_bank_onstate_mask(u8 bank)
+{
+ switch (bank) {
+ case 0:
+ return OMAP_MEM0_ONSTATE_MASK;
+ case 1:
+ return OMAP_MEM1_ONSTATE_MASK;
+ case 2:
+ return OMAP_MEM2_ONSTATE_MASK;
+ case 3:
+ return OMAP_MEM3_ONSTATE_MASK;
+ case 4:
+ return OMAP_MEM4_ONSTATE_MASK;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
EEXIST is the error code for File exists, so here I would rather
expect something like ENOENT. But I understand that it was already
-EEXIST in the existing code.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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 2/6] OMAP: powerdomain: Infrastructure to put arch specific code
On Tue, 16 Nov 2010 21:08:02 +0530
Rajendra Nayak rna...@ti.com wrote:
+struct pwrdm_functions {
+ int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_logic_retst)(struct powerdomain *pwrdm, u8 pwrst);
+ int (*pwrdm_set_mem_onst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_set_mem_retst)(struct powerdomain *pwrdm, u8 bank, u8
pwrst);
+ int (*pwrdm_read_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_prev_logic_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_logic_retst)(struct powerdomain *pwrdm);
+ int (*pwrdm_read_mem_pwrst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_read_prev_mem_pwrst)(struct powerdomain *pwrdm, u8
bank);
+ int (*pwrdm_read_mem_retst)(struct powerdomain *pwrdm, u8 bank);
+ int (*pwrdm_clear_all_prev_pwrst)(struct powerdomain *pwrdm);
+ int (*pwrdm_enable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
+ int (*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
+ int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
+};
It would probably be great to have some short documentation on this
structure, to detail what are the different operations, what they
should do, etc.
By the way, would pwrdm_operations be more linux-ish than
pwrdm_functions ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here: http://marc.info/?l=linux-omapm=127507237109393w=2 Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers. Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do. Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code. 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] i2c-omap: Set latency requirements only once for several messages
Samu Onkalo samu.p.onk...@nokia.com writes:
Ordinary I2C read consist of two messages. First a write operation
to tell register address and then read operation to get data.
CPU wake up latency is set and removed twice in read case.
Set latency requirement before the message processing loop
and remove the requirement after the loop to remove latency
adjustment operations between the messages.
Signed-off-by: Samu Onkalo samu.p.onk...@nokia.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Samu,
Can you collect the acks and repost to linux-...@vger.kernel.org
and Cc Ben Dooks ben-li...@fluff.org.
This one should go upstream via Ben.
Thanks,
Kevin
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b33c785..3e9323e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,12 +616,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- if (dev-set_mpu_wkup_lat != NULL)
- dev-set_mpu_wkup_lat(dev-dev, dev-latency);
r = wait_for_completion_timeout(dev-cmd_complete,
OMAP_I2C_TIMEOUT);
- if (dev-set_mpu_wkup_lat != NULL)
- dev-set_mpu_wkup_lat(dev-dev, -1);
dev-buf_len = 0;
if (r 0)
return r;
@@ -672,12 +668,18 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r 0)
goto out;
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-set_mpu_wkup_lat(dev-dev, dev-latency);
+
for (i = 0; i num; i++) {
r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num - 1)));
if (r != 0)
break;
}
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-set_mpu_wkup_lat(dev-dev, -1);
+
if (r == 0)
r = num;
--
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] OMAP: wd_timer: remove old, dead probing code
On Tue, 16 Nov 2010, Sergei Shtylyov wrote: On 16-11-2010 13:25, Paul Walmsley wrote: After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog Linus has asked to also specify the commit summary in parens... Thanks, will do. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions
* Cousson, Benoit b-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/partition if the current mux mode is not the default one. Here's one more patch that I'd like to merge into this patch to avoid repeating the partition for each mux entry. The memory vendors will not like you ;-) Assuming no more comments, I'll queue these for 2.6.38 merge window. I'll update the series and re-post tomorrow. Thanks, no need to post them again, I already have them queued locally, they will hit for-next and linux-omap master today. BTW, next time you do a git branch, please base it on Linus recent -rc tag instead of linux-omap master branch. We don't want the history of linux-omap master branch merged to the mainline tree.. Only if there are conflicts, then the git branches should be based on some other static commit that needs to be agreed separately. 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 0/8] OMAP2+: hwmod core upgrades for 2.6.38: first set
On Tue, 16 Nov 2010, Paul Walmsley wrote: This patch series contains upgrades for the OMAP2+ hwmod core code, intended for 2.6.38. Most of these patches were developed in response to use-cases discovered while converting device drivers to use the hwmod code. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. Just FYI, this branch 'hwmod_a_2.6.38' is available at git://git.pwsan.com/linux-2.6 Warning: it's based on Tony's tree, not the mainline, due to the recent board file changes. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP: wd_timer: update integration code to use new hwmod changes
On Tue, 16 Nov 2010, Paul Walmsley wrote: Update the OMAP watchdog timer integration code to take advantage of the new hwmod upgrades added by the OMAP2+: hwmod core upgrades for 2.6.38: first set series, posted previously. So that series needs to be applied before these patches. Charu, it would be great if you could take a look at these. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. And these patches are also available as 'wdt_2.6.38' from git://git.pwsan.com/linux-2.6 - 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
Grant Erickson maratho...@gmail.com writes:
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
How will this co-exist with the PWM on the twl6030 PMIC
(drivers/mfd/twl6030-pwm.c.)Both are exporting the same API.
Regarding multilpe PWM drivers, there has been discussion on the
linux-embedded list[1] regarding a more generic PWM framework, and a few
other projects working on PWM for OMAP[2]. Someone needs to step up and
consolidate/push this work forward as there is a clear need for a more
generic PWM infrastructure on various SoCs. Your work is another
example of similar work that needs to be coordinated with the other projects.
Boards can register such devices using platform data such as in the following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
.polarity = 1 // Active-high
};
Board code should not have to know which timers are PWM capable. This
information is fixed at the SoC level.
This information is available and is part of the in-progress conversion
of the timers to use the omap_hwmod infrastructure. There are subsets
of the timers that have various features (1ms timers, PWM capable, etc.)
Using hwmod classes, they can be grouped together such that board code
does not have to know which timers on which SoC are PWM capable. It
can simply request a timer with certain capabilities.
Kevin
[1] http://marc.info/?l=linux-embeddedm=128594628918269w=2
[2] http://marc.info/?l=linux-embeddedm=128599642406671w=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 2/7] OMAP: mux: Add support for control module split in several partitions
Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/partition if the current mux mode is not the default one. Here's one more patch that I'd like to merge into this patch to avoid repeating the partition for each mux entry. The memory vendors will not like you ;-) Assuming no more comments, I'll queue these for 2.6.38 merge window. I'll update the series and re-post tomorrow. Thanks, no need to post them again, I already have them queued locally, they will hit for-next and linux-omap master today. OK, but I already did it because there is a checkpatch issue in your first patch and I received another patch from Dan to add __func__ in the pr_xxx macros. I can repost, or you can get the update in my GIT (ctrl-wip/mux-omap4-v4). BTW, next time you do a git branch, please base it on Linus recent -rc tag instead of linux-omap master branch. We don't want the history of linux-omap master branch merged to the mainline tree.. Euh, this is what I already did for this series. Quoting myself: The series is based on mainline (2.6.37-rc1) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v3 Did I messed up something? Regards, Benoit -- 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/5] crypto: omap-aes: change in prevention of OCP bus error
Hi, * Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:18]: Suggested to use udelay() instead of nop as on the higher core frequencies it might not be enough time. Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com --- drivers/crypto/omap-aes.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 799ca51..9d65611 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -26,6 +26,7 @@ #include linux/io.h #include linux/crypto.h #include linux/interrupt.h +#include linux/delay.h #include crypto/scatterwalk.h #include crypto/aes.h @@ -187,11 +188,12 @@ static int omap_aes_hw_init(struct omap_aes_dev *dd) omap_aes_write_mask(dd, AES_REG_MASK, AES_REG_MASK_SOFTRESET, AES_REG_MASK_SOFTRESET); /* - * prevent OCP bus error (SRESP) in case an access to the module - * is performed while the module is coming out of soft reset + * prevent OCP bus error (SRESP) on OMAP3630 in case an access + * to the module is performed while the module is + * coming out of soft reset */ - __asm__ __volatile__(nop); - __asm__ __volatile__(nop); + if (cpu_is_omap3630()) + udelay(1); err = omap_aes_wait(dd, AES_REG_SYSSTATUS, AES_REG_SYSSTATUS_RESETDONE); Please don't add more cpu_is_omap tests into drivers, those will be limited to arch/arm/*omap*/ platform init code soonish. The drivers should be generic. Instead, check the crypto hardware version during init. If that does not work, pass u32 flags in the platform data and define OMAP_AES_SOFT_RESET_ERROR bit. 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 1/7] crypto: updates omap sham device related platform code
* Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:20]:
- registration with multi OMAP kernels support
- clocks
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/devices.c | 58
+++-
arch/arm/plat-omap/include/plat/omap34xx.h |5 ++
5 files changed, 56 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d932b14..1820a55 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1836,7 +1836,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, vlynq_ick,vlynq_ick, CK_242X),
CLK(NULL, vlynq_fck,vlynq_fck, CK_242X),
CLK(NULL, des_ick, des_ick, CK_242X),
- CLK(NULL, sha_ick, sha_ick, CK_242X),
+ CLK(omap-sham,ick, sha_ick, CK_242X),
CLK(omap_rng, ick, rng_ick, CK_242X),
CLK(NULL, aes_ick, aes_ick, CK_242X),
CLK(NULL, pka_ick, pka_ick, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 0438b6e..5884ac6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1924,7 +1924,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, sdma_ick, sdma_ick, CK_243X),
CLK(NULL, sdrc_ick, sdrc_ick, CK_243X),
CLK(NULL, des_ick, des_ick, CK_243X),
- CLK(NULL, sha_ick, sha_ick, CK_243X),
+ CLK(omap-sham,ick, sha_ick, CK_243X),
CLK(omap_rng, ick, rng_ick, CK_243X),
CLK(NULL, aes_ick, aes_ick, CK_243X),
CLK(NULL, pka_ick, pka_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 9cba556..52638df 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3360,7 +3360,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(mmci-omap-hs.2, ick, mmchs3_ick,CK_3430ES2 | CK_AM35XX),
CLK(NULL, icr_ick, icr_ick, CK_343X),
CLK(NULL, aes2_ick, aes2_ick, CK_343X),
- CLK(NULL, sha12_ick,sha12_ick, CK_343X),
+ CLK(omap-sham,ick, sha12_ick, CK_343X),
CLK(NULL, des2_ick, des2_ick, CK_343X),
CLK(mmci-omap-hs.1, ick, mmchs2_ick,CK_3XXX),
CLK(mmci-omap-hs.0, ick, mmchs1_ick,CK_3XXX),
This looks OK.
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..beac46c 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,6 +26,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
+#include plat/dma.h
#include mux.h
@@ -453,8 +454,10 @@ static void omap_init_mcspi(void)
static inline void omap_init_mcspi(void) {}
#endif
-#ifdef CONFIG_OMAP_SHA1_MD5
-static struct resource sha1_md5_resources[] = {
+#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
+
+#ifdef CONFIG_ARCH_OMAP24XX
+static struct resource omap2_sham_resources[] = {
{
.start = OMAP24XX_SEC_SHA1MD5_BASE,
.end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
@@ -465,20 +468,55 @@ static struct resource sha1_md5_resources[] = {
.flags = IORESOURCE_IRQ,
}
};
+static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
+#else
+#define omap2_sham_resources NULL
+#define omap2_sham_resources_sz 0
+#endif
-static struct platform_device sha1_md5_device = {
- .name = OMAP SHA1/MD5,
+#ifdef CONFIG_ARCH_OMAP34XX
+static struct resource omap3_sham_resources[] = {
+ {
+ .start = OMAP34XX_SEC_SHA1MD5_BASE,
+ .end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_34XX_SHA1MD52_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP34XX_DMA_SHA1MD5_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
+#else
+#define omap3_sham_resources NULL
+#define omap3_sham_resources_sz 0
+#endif
+
+static struct platform_device sham_device = {
+ .name = omap-sham,
.id = -1,
- .num_resources = ARRAY_SIZE(sha1_md5_resources),
- .resource = sha1_md5_resources,
};
-static void
Re: [PATCH 3/7] omap-sham: OMAP macros corrected
* Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:20]:
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
arch/arm/mach-omap2/devices.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index beac46c..79dbf04 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -456,7 +456,7 @@ static inline void omap_init_mcspi(void) {}
#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) ||
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
-#ifdef CONFIG_ARCH_OMAP24XX
+#ifdef CONFIG_ARCH_OMAP2
static struct resource omap2_sham_resources[] = {
{
.start = OMAP24XX_SEC_SHA1MD5_BASE,
@@ -474,7 +474,7 @@ static int omap2_sham_resources_sz =
ARRAY_SIZE(omap2_sham_resources);
#define omap2_sham_resources_sz 0
#endif
-#ifdef CONFIG_ARCH_OMAP34XX
+#ifdef CONFIG_ARCH_OMAP3
static struct resource omap3_sham_resources[] = {
{
.start = OMAP34XX_SEC_SHA1MD5_BASE,
I think we already fixed these a while back..
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 5/8] OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex
Hi Paul,
Funny, I was about to send you a RFC to get rid of that mutex :-)
Today that mutex is preventing us to be re-entrant during hwmod lookup
and for_each_by_class iteration, and we'd like to in order to manage
link between 2 hwmods.
The context is the link between mcbsp and sidetone on OMAP3. Since this
module are tightly coupled, I was suggesting to Kishon to add the
sidetone reference directly in the mcbsp hwmod in order to create a
omap_device that will handle the 2 hwmods at the same time.
Since we are using the iteration to get all the hwmod that belongs to
the mcbsp class we cannot call the lookup function to get the sidetone
hwmod at that time.
For the moment we need to do 2 iteration and use intermediate storage to
workaround that.
After checking the purpose of the mutex, I was wondering if this is
useful. For the moment the creation of the hwmod list is done only at
init time, and nothing is supposed to change that at runtime except the
unregister function.
So I've started to get rid of this function, then of the mutex and I
added the __init to all these registration functions to avoid the usage
at runtime. It will save a little bit of memory as well.
Thanks to that we can now use the omap_hwmod_lookup inside the
omap_hwmod_for_each_by_class.
Does that make sense to you?
I can send you the patches if you want.
Regards,
Benoit
On 11/16/2010 11:18 AM, Paul Walmsley wrote:
This trivial patch renames omap_hwmod_mutex to _hwmod_list_mutex to indicate
clearly that it is only used for hwmod list manipulation operations.
Signed-off-by: Paul Walmsleyp...@pwsan.com
Cc: Benoît Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12a0b9a..0e85278 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,7 +156,8 @@
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
-static DEFINE_MUTEX(omap_hwmod_mutex);
+/* _hwmod_list_mutex protects the list of registered hwmods */
+static DEFINE_MUTEX(_hwmod_list_mutex);
/* mpu_oh: used to add/remove MPU initiator from sleepdep list */
static struct omap_hwmod *mpu_oh;
@@ -874,7 +875,7 @@ static void _shutdown_sysc(struct omap_hwmod *oh)
* @name: find an omap_hwmod by name
*
* Return a pointer to an omap_hwmod by name, or NULL if not found.
- * Caller must hold omap_hwmod_mutex.
+ * Caller must hold _hwmod_list_mutex.
*/
static struct omap_hwmod *_lookup(const char *name)
{
@@ -1502,7 +1503,7 @@ int omap_hwmod_register(struct omap_hwmod *oh)
(oh-_state != _HWMOD_STATE_UNKNOWN))
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
pr_debug(omap_hwmod: %s: registering\n, oh-name);
@@ -1528,7 +1529,7 @@ int omap_hwmod_register(struct omap_hwmod *oh)
ret = 0;
ohr_unlock:
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return ret;
}
@@ -1546,9 +1547,9 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name)
if (!name)
return NULL;
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
oh = _lookup(name);
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return oh;
}
@@ -1574,13 +1575,13 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod
*oh, void *data),
if (!fn)
return -EINVAL;
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
list_for_each_entry(temp_oh,omap_hwmod_list, node) {
ret = (*fn)(temp_oh, data);
if (ret)
break;
}
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return ret;
}
@@ -1663,10 +1664,10 @@ int omap_hwmod_unregister(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: unregistering\n, oh-name);
- mutex_lock(omap_hwmod_mutex);
+ mutex_lock(_hwmod_list_mutex);
iounmap(oh-_mpu_rt_va);
list_del(oh-node);
- mutex_unlock(omap_hwmod_mutex);
+ mutex_unlock(_hwmod_list_mutex);
return 0;
}
@@ -2125,7 +2126,7 @@ int omap_hwmod_read_hardreset(struct omap_hwmod *oh,
const char *name)
* @user: arbitrary context data to pass to the callback function
*
* For each omap_hwmod of class @classname, call @fn. Takes
- * omap_hwmod_mutex to prevent the hwmod list from changing during the
+ * _hwmod_list_mutex to prevent the hwmod list from changing during the
* iteration. If the callback function returns something other than
* zero, the iterator is terminated, and the callback function's return
* value is passed back to the caller. Returns 0 upon success, -EINVAL
@@ -2145,7
Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions
* Cousson, Benoit b-cous...@ti.com [101116 08:53]: Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/partition if the current mux mode is not the default one. Here's one more patch that I'd like to merge into this patch to avoid repeating the partition for each mux entry. The memory vendors will not like you ;-) Assuming no more comments, I'll queue these for 2.6.38 merge window. I'll update the series and re-post tomorrow. Thanks, no need to post them again, I already have them queued locally, they will hit for-next and linux-omap master today. OK, but I already did it because there is a checkpatch issue in your first patch and I received another patch from Dan to add __func__ in the pr_xxx macros. I can repost, or you can get the update in my GIT (ctrl-wip/mux-omap4-v4). OK, if they're changed maybe repost the whole series one more time, and then I'll merge in your branch assuming no more comments. BTW, next time you do a git branch, please base it on Linus recent -rc tag instead of linux-omap master branch. We don't want the history of linux-omap master branch merged to the mainline tree.. Euh, this is what I already did for this series. Quoting myself: The series is based on mainline (2.6.37-rc1) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v3 Did I messed up something? No, mux-omap4-v4 branch looks OK. I guess what I tried pulling was something older. 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
On 11/16/10 4:37 AM, Hemanth V wrote:
- Original Message -
From: Grant Erickson maratho...@gmail.com
Sent: Monday, November 15, 2010 12:58 AM
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
Generally PWMs are supported on PMIC chip. Is this driver intended for use
when OMAP is used standalone?
Correct.
Boards can register such devices using platform data such as in the
following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
Since only specific GPTs can be configured for PWM, can some check
we added in probe function?
Yes, that check is already present in the probe function:
pwm-dm_timer = omap_dm_timer_request_specific(pdata-timer_id);
if (pwm-dm_timer == NULL) {
status = -ENOENT;
goto err_free;
}
Can the above file be part of mach-omap2, since comment say its
specifically for OMAP2/3 or will this work on OMAP1 also?
It should work wherever dmtimers are supported. To the extent that dmtimer.c
is in plat-omap/, I located pwm.c there as well.
Thanks for the feedback!
Best,
Grant
--
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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
On 11/16/10 4:42 AM, Felipe Balbi wrote: On Sun, Nov 14, 2010 at 01:28:49PM -0600, Grant Erickson wrote: +MODULE_LICENSE(GPLv2); module license should be GPL v2 Thanks for the feedback. I'll make that adjustment. Best, Grant -- 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: omap4: hsmmc: Fix improper card detection while booting
* kishore kadiyala kishore.kadiy...@ti.com [101115 00:59]:
While booting OMAP4 ES2.0 boards, cards on MMC1 and MMC2 controllers
are not getting detected some times.
During reset of command/data line, wrong pointer to base address
was passed while read operation to SYSCTL register, thus impacting
the updated reset logic.
Passing correct base address fixes the issue.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Felipie Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Chris Ball c...@laptop.org
Cc: Madhusudhan Chikkature madhu...@ti.com
Good find:
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82a1079..5d46021 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1002,7 +1002,7 @@ static inline void
omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host
*host,
* Monitor a 0-1 transition first
*/
if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
- while ((!(OMAP_HSMMC_READ(host, SYSCTL) bit))
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
cpu_relax();
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: enable L2 prefetching
* Måns Rullgård m...@mansr.com [101115 09:01]: Nishanth Menon n...@ti.com writes: From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it, even though it damages writes a bit. (rebased to k.org) Usually the prefetch is used at both levels together L1 + L2, however, to enable the CP15 prefetch engines, these are under security, and on GP devices, we cannot enable it(e.g. on PandaBoard). However, just enabling PL310 prefetch seems to provide performance improvement, as shown in the data below (from Ubuntu) and would be a great thing to pull in. What this does is enable automatic next line prefetching. With this enabled, whenever the PL310 receives a cachable read request, it automatically prefetches the following cache line as well. A larger offset can be programmed in secure mode, but the TI ROM authors neglected to include this. Testing with FFmpeg showed a speedup of 10% with this patch in some cases. Måns and Nishant, care to repost this with the updated comments? 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
On 11/16/10 9:01 AM, Kevin Hilman wrote:
Grant Erickson maratho...@gmail.com writes:
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
How will this co-exist with the PWM on the twl6030 PMIC
(drivers/mfd/twl6030-pwm.c.)? Both are exporting the same API.
That's an excellent question. This driver started life in the 2.6.32 tree
where twl6030-pwm.c didn't exist. Thanks for the heads-up.
The right short-term solution is to probably change the configuration from:
config HAVE_PWM
to:
config OMAP_PWM
select HAVE_PWM
and then have it conflict with TWL6030_PWM if that's enabled.
Regarding multilpe PWM drivers, there has been discussion on the
linux-embedded list[1] regarding a more generic PWM framework, and a few
other projects working on PWM for OMAP[2]. Someone needs to step up and
consolidate/push this work forward as there is a clear need for a more
generic PWM infrastructure on various SoCs. Your work is another
example of similar work that needs to be coordinated with the other projects.
Boards can register such devices using platform data such as in the following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
.polarity = 1 // Active-high
};
Board code should not have to know which timers are PWM capable. This
information is fixed at the SoC level.
Fair enough; however, board code does have to know which PWM outputs are
tied to which piece of hardware being driven by it. In the OMAP3, there
isn't an any-to-any mapping of PWM timers to PWM-capable output pins.
So, in this case, I explicitly:
1) configure that pin multiplexer as GPT10_PWM_EVT.
2) make available GPT10_PWM_EVT as a generic PWM because that's the one
precisely tied to the display backlight.
3) ensure that the backlight driver asks for the right generic PWM
associated with it.
This information is available and is part of the in-progress conversion
of the timers to use the omap_hwmod infrastructure. There are subsets
of the timers that have various features (1ms timers, PWM capable, etc.)
Using hwmod classes, they can be grouped together such that board code
does not have to know which timers on which SoC are PWM capable. It
can simply request a timer with certain capabilities.
Kevin
[1] http://marc.info/?l=linux-embeddedm=128594628918269w=2
[2] http://marc.info/?l=linux-embeddedm=128599642406671w=2
I'll take a look at those references.
With the appropriate configuration change to avoid the conflict with
TWL6030-PWM, it's probably better to have this driver in-tree than not.
It'll give those working on the PWM abstraction and rework another working
use case to integrate and work from.
Thanks for the feedback and the references.
Best,
Grant
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions
On 11/16/2010 6:37 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101116 08:53]: Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com[10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time depending of Soc partitioning. - Add some init flags as well in order to avoid explicit Soc version check inside the mux core code. - Add a comment with mux0 mode on top of omap_mux/board/partition if the current mux mode is not the default one. Here's one more patch that I'd like to merge into this patch to avoid repeating the partition for each mux entry. The memory vendors will not like you ;-) Assuming no more comments, I'll queue these for 2.6.38 merge window. I'll update the series and re-post tomorrow. Thanks, no need to post them again, I already have them queued locally, they will hit for-next and linux-omap master today. OK, but I already did it because there is a checkpatch issue in your first patch and I received another patch from Dan to add __func__ in the pr_xxx macros. I can repost, or you can get the update in my GIT (ctrl-wip/mux-omap4-v4). OK, if they're changed maybe repost the whole series one more time, and then I'll merge in your branch assuming no more comments. BTW, next time you do a git branch, please base it on Linus recent -rc tag instead of linux-omap master branch. We don't want the history of linux-omap master branch merged to the mainline tree.. Euh, this is what I already did for this series. Quoting myself: The series is based on mainline (2.6.37-rc1) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v3 Did I messed up something? No, mux-omap4-v4 branch looks OK. I guess what I tried pulling was something older. The v2 was done before the 2.6.37-rc1 and was dependent of the ES2 support that's why it was based on l-o/master. Starting on v3, I rebased everything on mainline. I'll post the v4 revision. Benoit -- 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
Grant Erickson maratho...@gmail.com writes:
On 11/16/10 9:01 AM, Kevin Hilman wrote:
Grant Erickson maratho...@gmail.com writes:
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
How will this co-exist with the PWM on the twl6030 PMIC
(drivers/mfd/twl6030-pwm.c.)? Both are exporting the same API.
That's an excellent question. This driver started life in the 2.6.32 tree
where twl6030-pwm.c didn't exist. Thanks for the heads-up.
The right short-term solution is to probably change the configuration from:
config HAVE_PWM
to:
config OMAP_PWM
select HAVE_PWM
and then have it conflict with TWL6030_PWM if that's enabled.
And what happens when other PWM sources are added?
Regarding multilpe PWM drivers, there has been discussion on the
linux-embedded list[1] regarding a more generic PWM framework, and a few
other projects working on PWM for OMAP[2]. Someone needs to step up and
consolidate/push this work forward as there is a clear need for a more
generic PWM infrastructure on various SoCs. Your work is another
example of similar work that needs to be coordinated with the other projects.
Boards can register such devices using platform data such as in the
following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
.polarity = 1 // Active-high
};
Board code should not have to know which timers are PWM capable. This
information is fixed at the SoC level.
Fair enough; however, board code does have to know which PWM outputs are
tied to which piece of hardware being driven by it. In the OMAP3, there
isn't an any-to-any mapping of PWM timers to PWM-capable output pins.
So, in this case, I explicitly:
1) configure that pin multiplexer as GPT10_PWM_EVT.
2) make available GPT10_PWM_EVT as a generic PWM because that's the one
precisely tied to the display backlight.
3) ensure that the backlight driver asks for the right generic PWM
associated with it.
This information is available and is part of the in-progress conversion
of the timers to use the omap_hwmod infrastructure. There are subsets
of the timers that have various features (1ms timers, PWM capable, etc.)
Using hwmod classes, they can be grouped together such that board code
does not have to know which timers on which SoC are PWM capable. It
can simply request a timer with certain capabilities.
Kevin
[1] http://marc.info/?l=linux-embeddedm=128594628918269w=2
[2] http://marc.info/?l=linux-embeddedm=128599642406671w=2
I'll take a look at those references.
With the appropriate configuration change to avoid the conflict with
TWL6030-PWM, it's probably better to have this driver in-tree than not.
Well, Tony will make the final call here, but I disagree that this
should merge in its current form.
Before something like this can merge, I would rather see
1) generic PWM framework pushed along and merged
2) the dmtimer hwmod conversion finished
Yes, I know it's a lot more work to fix the core/framework code before
having a feature included, but having something more generic that can
actually support multiple PWM sources is clearly needed.
Kevin
It'll give those working on the PWM abstraction and rework another working
use case to integrate and work from.
Thanks for the feedback and the references.
Best,
Grant
--
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: enable L2 prefetching
Nishanth Menon n...@ti.com writes: From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it, even though it damages writes a bit. (rebased to k.org) Usually the prefetch is used at both levels together L1 + L2, however, to enable the CP15 prefetch engines, these are under security, and on GP devices, we cannot enable it(e.g. on PandaBoard). However, just enabling PL310 prefetch seems to provide performance improvement, as shown in the data below (from Ubuntu) and would be a great thing to pull in. [...] arch/arm/mach-omap2/omap4-common.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 2f89555..a5e6126 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -64,6 +64,10 @@ static int __init omap_l2_cache_init(void) l2cache_base = ioremap(OMAP44XX_L2CACHE_BASE, SZ_4K); BUG_ON(!l2cache_base); + if (omap_rev() != OMAP4430_REV_ES1_0) + omap_smc1(0x109, 0x7e47); /* Enable PL310 L2 Cache controller */ omap_smc1(0x102, 0x1); @@ -75,7 +79,7 @@ static int __init omap_l2_cache_init(void) if (omap_rev() == OMAP4430_REV_ES1_0) l2x0_init(l2cache_base, 0x0e05, 0xcfff); else - l2x0_init(l2cache_base, 0x0e07, 0xcfff); + l2x0_init(l2cache_base, 0x7e47, 0xcfff); /* * Override default outer_cache.disable with a OMAP4 Adding/updaing the in-code comments would be helpful as well. The exiting use of all the hard-coded constants in this code is rather unreadable and would be much more readable with symbolic constants, and this change just continues the pattern. Ideally, switching this code to use symbolic constants and then adding the new feature would be a cleaner approach. 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
[PATCH v4 2/3] omap4: opp: add OPP table data
This patch adds OPP tables for OMAP4. New file has been added to keep
the OMAP4 opp tables and the registration of these tables with the
generic opp framework by OMAP SoC OPP interface.
Based on:
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blob;f=arch/arm/mach-omap2/opp44xx_data.c;h=252e3d0cb6050a64f390b9311c1c4977d74f762a;hb=refs/heads/omap4_next
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP4 in Kconfig
V4: switched data to .c file
v3: http://marc.info/?l=linux-omapm=128984926712794w=2
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266921/
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/opp.c |3 +-
arch/arm/mach-omap2/opp4xxx_data.c | 49
arch/arm/mach-omap2/pm.h |5 +++
4 files changed, 57 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 93a91ff..0f1855a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -45,6 +45,7 @@ config ARCH_OMAP4
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789
+ select PM_OPP if PM
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 66e12be..48a553f 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -131,4 +131,5 @@ static int __init omap_init_opp_table(struct omap_opp_def
*opp_def,
/* omap3 opps */
#include opp3xxx_data.c
-
+/* omap4 opps */
+#include opp4xxx_data.c
diff --git a/arch/arm/mach-omap2/opp4xxx_data.c
b/arch/arm/mach-omap2/opp4xxx_data.c
new file mode 100644
index 000..6271774
--- /dev/null
+++ b/arch/arm/mach-omap2/opp4xxx_data.c
@@ -0,0 +1,49 @@
+/*
+ * OMAP4 OPP table definitions.
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ * Copyright (C) 2010 Texas Instruments Incorporated.
+ * Thara Gopinath
+ *
+ * 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.
+ */
+
+static struct omap_opp_def __initdata omap44xx_opp_def_list[] = {
+ /* MPU OPP1 - OPP50 */
+ OPP_INITIALIZER(mpu, true, 3, 110),
+ /* MPU OPP2 - OPP100 */
+ OPP_INITIALIZER(mpu, true, 6, 120),
+ /* MPU OPP3 - OPP-Turbo */
+ OPP_INITIALIZER(mpu, false, 8, 126),
+ /* MPU OPP4 - OPP-SB */
+ OPP_INITIALIZER(mpu, false, 100800, 135),
+ /* L3 OPP1 - OPP50 */
+ OPP_INITIALIZER(l3_main_1, true, 1, 93),
+ /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OPP_INITIALIZER(l3_main_1, true, 2, 110),
+ /* TODO: add IVA, DSP, aess, fdif, gpu */
+};
+
+/**
+ * omap4_opp_init() - initialize omap4 opp table
+ */
+int __init omap4_opp_init(void)
+{
+ int r = -ENODEV;
+
+ if (!cpu_is_omap44xx())
+ return r;
+
+ r = omap_init_opp_table(omap44xx_opp_def_list,
+ ARRAY_SIZE(omap44xx_opp_def_list));
+
+ return r;
+}
+device_initcall(omap4_opp_init);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 2031f15..a43e069 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,11 +22,16 @@ extern int omap3_idle_init(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
+extern int omap4_opp_init(void);
#else
static inline int omap3_opp_init(void)
{
return -EINVAL;
}
+static inline int omap4_opp_init(void)
+{
+ return -EINVAL;
+}
#endif
struct cpuidle_params {
--
1.6.3.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
[PATCH v3 3/3] OMAP3: remove OPP interfaces from OMAP PM layer
From: Kevin Hilman khil...@deeprootsystems.com
With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
posted for completeness sake - no change involved
v3: no longer explicitly calling the init_table, instead
depending on the device_initcall to initialize as needed
v2: https://patchwork.kernel.org/patch/266931/
arch/arm/mach-omap2/io.c |3 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 31 +---
arch/arm/plat-omap/omap-pm-noop.c | 11 +-
3 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..2fe4e02 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -327,8 +327,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
*sdrc_cs0,
else if (cpu_is_omap44xx())
omap44xx_hwmod_init();
- /* The OPP tables have to be registered before a clk init */
- omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+ omap_pm_if_early_init();
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..62c3fe9 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -17,27 +17,10 @@
#include linux/device.h
#include linux/cpufreq.h
#include linux/clk.h
+#include linux/opp.h
#include powerdomain.h
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data. Can vary by OMAP chip and board.
- */
-struct omap_opp {
- unsigned long rate;
- u8 opp_id;
- u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
-
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
*
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
* framework starts. The _if_ is to avoid name collisions with the
* PM idle-loop code.
*/
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
/**
* omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp
*mpu_opp_table,
* The main initialization code. OPP tables are passed in here. The
* _if_ is to avoid name collisions with the PM idle-loop code.
*/
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
int __init omap_pm_if_init(void);
+#endif
/**
* omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
#include plat/powerdomain.h
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
/*
* Device-driver-originated constraints (via board-*.c files)
*/
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
/* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
{
- mpu_opps = mpu_opp_table;
- dsp_opps = dsp_opp_table;
- l3_opps = l3_opp_table;
return 0;
}
--
1.6.3.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
[PATCH v4 1/3] omap: opp: add OMAP3 OPP table data and common init
Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.
introduce an OMAP generic opp initialization routine which OMAP3
and OMAP4+ SoCs can use to register their OPP definitions.
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Warning: http://lkml.org/lkml/2010/11/9/389
Introduces ARCH_HAS_OPP which needs to be enabled as well
for OMAP3 in the Kconfig
v4:
Comments from Thomas addressed:
* Data switched to .c file and the c file included in opp.c
* init_table will fail with -EEXIST if already called
* minor comment improvements
Not addressed:
* request for board files to explicitly call init table
as discussed http://marc.info/?l=linux-omapm=128992417530385w=2
v3: http://marc.info/?t=12898493916r=1w=2
* added documentation for custom opp modification
by board files
* switched to using device_initcall to autoinitialize the
opp tables
v2: https://patchwork.kernel.org/patch/266911/
Documentation/arm/OMAP/omap_pm | 26 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/opp.c | 134
arch/arm/mach-omap2/opp3xxx_data.c | 98 ++
arch/arm/mach-omap2/pm.h |9 +++
6 files changed, 270 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/opp.c
create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..88341f0 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,29 @@ implementation needs:
10. (*pdata-cpu_set_freq)(unsigned long f)
11. (*pdata-cpu_get_freq)(void)
+
+Customizing OPP for platform
+
+Defining CONFIG_PM should enable OPP layer for the silicon
+and the registration of OPP table should take place automatically.
+However, in special cases, the default OPP table may need to be
+tweaked, for e.g.:
+ * enable default OPPs which are disabled by default, but which
+ could be enabled on a platform
+ * Disable an unsupported OPP on the platform
+ * Define and add a custom opp table entry
+in these cases, the board file needs to do additional steps as follows:
+arch/arm/mach-omapx/board-xyz.c
+ #include pm.h
+
+ static void __init omap_xyz_init_irq(void)
+ {
+
+ /* Initialize the default table */
+ omapx_opp_init();
+ /* Do customization to the defaults */
+
+ }
+NOTE: omapx_opp_init will be omap3_opp_init or as required
+based on the omap family.
+
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..93a91ff 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,6 +35,7 @@ config ARCH_OMAP3
select CPU_V7
select USB_ARCH_HAS_EHCI
select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
+ select PM_OPP if PM
config ARCH_OMAP4
bool TI OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 60e51bc..1650a62 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,6 +64,8 @@ endif
endif
+obj-$(CONFIG_PM_OPP) += opp.o
+
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
obj-$(CONFIG_ARCH_OMAP3) += cm.o
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
new file mode 100644
index 000..66e12be
--- /dev/null
+++ b/arch/arm/mach-omap2/opp.c
@@ -0,0 +1,134 @@
+/*
+ * OMAP SoC specific OPP wrapper function
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * 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/module.h
+#include linux/err.h
+#include linux/opp.h
+
+#include plat/cpu.h
+#include plat/omap_device.h
+
+#include pm.h
+
+/**
+ * struct omap_opp_def - OMAP OPP Definition
+ * @hwmod_name:Name of the hwmod for this domain
+ * @freq: Frequency in hertz corresponding to this OPP
+ * @u_volt:Nominal voltage in microvolts corresponding to this OPP
+ * @enabled: True/false - is this OPP enabled/disabled by default
+ *
+ * OMAP SOCs have a standard set of tuples consisting of frequency and voltage
+ * pairs that the device will support per voltage domain. This is called
+ * Operating Points or OPP. The actual definitions of OMAP Operating Points
+ * varies
[PATCH v4 0/3] OMAP: Add opp data
Major changes in V4: Rename of oppxxx_data.h to data.c, move device_init there omap_init_opp_table now will return -EEXIST if it was called previously. V3: http://marc.info/?l=linux-omapm=128984926812800w=2 V2: http://marc.info/?t=12875366533r=1w=2 Kevin Hilman (1): OMAP3: remove OPP interfaces from OMAP PM layer Nishanth Menon (2): omap: opp: add OMAP3 OPP table data and common init omap4: opp: add OPP table data Documentation/arm/OMAP/omap_pm| 26 ++ arch/arm/mach-omap2/Kconfig |2 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/io.c |3 +- arch/arm/mach-omap2/opp.c | 135 + arch/arm/mach-omap2/opp3xxx_data.c| 98 + arch/arm/mach-omap2/opp4xxx_data.c| 49 +++ arch/arm/mach-omap2/pm.h | 14 +++ arch/arm/plat-omap/include/plat/omap-pm.h | 31 ++- arch/arm/plat-omap/omap-pm-noop.c | 11 +-- 10 files changed, 338 insertions(+), 33 deletions(-) create mode 100644 arch/arm/mach-omap2/opp.c create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c Regards, Nishanth Menon -- 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Grant Erickson
Sent: Monday, November 15, 2010 12:59 AM
To: linux-omap@vger.kernel.org
Cc: Tony Lindgren
Subject: [PATCH] Add OMAP Support for Generic PWM Devices
using Dual-mode Timers
This patch adds support to request and use one or more of the OMAP
dual-mode timers as a generic PWM device compatible with other generic
PWM drivers such as the PWM backlight or PWM beeper driver.
Boards can register such devices using platform data such as
in the following
example:
static struct omap2_pwm_platform_config pwm_config = {
.timer_id = 10, // GPT10_PWM_EVT
.polarity = 1 // Active-high
};
static struct platform_device pwm_device = {
.name = omap-pwm,
.id = 0,
.dev= {
.platform_data = pwm_config
}
};
Signed-off-by: Grant Erickson maratho...@gmail.com
[snip]...[snip]
[sp] Few additional comments that should be considered while submitting
next patch revision.
+/* Preprocessor Definitions */
+
+#undef OMAP_PWM_DEBUG
+
+#if defined(OMAP_PWM_DEBUG)
+#define DBG(args...) \
+ do {\
+ pr_info(args); \
+ } while (0)
+#define DEV_DBG(dev, args...)\
+ do {\
+ dev_info(dev, args);\
+ } while (0)
+#else
+#define DBG(args...) \
+ do { } while (0)
+#define DEV_DBG(dev, args...)\
+ do { } while (0)
+#endif /* defined(OMAP_PWM_DEBUG) */
[sp] pr_info(), dev_info() are already macros - conditional to DEBUG.
We should use them instead of defining another layer.
+
+#define DM_TIMER_LOAD_MIN0xFFFE
+
+/* Type Definitions */
+
+/**
+ * struct pwm_device - opaque internal PWM device instance state
+ * @head: list head for all PWMs managed by this driver.
+ * @pdev: corresponding platform device associated with this
device instance.
+ * @dm_timer: corresponding dual-mode timer associated with
this device
+ * instance.
+ * @config: platform-specific configuration data.
+ * @label: description label.
+ * @use_count: use count.
+ * @pwm_id: generic PWM ID requested for this device instance.
+ *
+ * As far as clients of the PWM driver are concerned, PWM devices are
+ * opaque abstract objects. Consequently, this structure is used for
+ * tracking internal device instance state but is otherwise just a
+ * instance reference externally.
+ */
+
+struct pwm_device {
+ struct list_head head;
+ struct platform_device*pdev;
+ struct omap_dm_timer *dm_timer;
+ struct omap2_pwm_platform_config config;
+ const char
*label;
+ unsigned int use_count;
+ unsigned int pwm_id;
+};
[sp] This block has mix of tabs and white spaces. We should be consistent.
There are similar instances below as well...
You may also want to line up the field names - they start at different
columns.
+
+/* Function Prototypes */
+
+static int __devinit omap_pwm_probe(struct platform_device *pdev);
+static int __devexit omap_pwm_remove(struct platform_device *pdev);
+
+/* Global Variables */
+
+static struct platform_driver omap_pwm_driver = {
+ .driver = {
+ .name = omap-pwm,
+ .owner = THIS_MODULE,
+ },
+ .probe = omap_pwm_probe,
+ .remove = __devexit_p(omap_pwm_remove)
+};
+
+/* List and associated lock for managing generic PWM devices bound to
+ * this driver.
+ */
+
[sp] White space not needed. Similar instances below as well.
+static DEFINE_MUTEX(pwm_lock);
+static LIST_HEAD(pwm_list);
+
[snip]...[snip]
+/**
+ * pwm_config - configures the generic PWM device to the
specified parameters.
+ * @pwm: A pointer to the PWM device to configure.
+ * @duty_ns: The duty period of the PWM, in nanoseconds.
+ * @period_ns: The overall period of the PWM, in nanoseconds.
+ *
+ * Returns 0 if the generic PWM device was successfully configured;
+ * otherwise, 0 on error.
+ */
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+ int status = 0;
+ const bool enable = true;
+ const bool autoreload = true;
+ const bool toggle = true;
+ const int trigger = OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE;
[sp] Based on code abobe, I believe that OMAP...COMPARE is macro;
shouldn't we use it as is - where trigger is used in code below?
+ int load_value, match_value;
+ unsigned long
Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
On 11/16/10 10:54 AM, Premi, Sanjeev wrote:
[sp] pr_info(), dev_info() are already macros - conditional to DEBUG.
We should use them instead of defining another layer.
The macros pr_devel, pr_dbg, and dev_dbg are so conditionalized; however,
*_info are straight pass-throughs to printk and dev_printk, respectively.
+struct pwm_device {
+ struct list_head head;
+ struct platform_device *pdev;
+ struct omap_dm_timer *dm_timer;
+ struct omap2_pwm_platform_config config;
+ const char
*label;
+ unsigned intuse_count;
+ unsigned intpwm_id;
+};
[sp] This block has mix of tabs and white spaces. We should be consistent.
There are similar instances below as well...
You may also want to line up the field names - they start at different
columns.
Will do. Oddly, these sailed through checkpatch.pl.
+int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+ int status = 0;
+ const bool enable = true;
+ const bool autoreload = true;
+ const bool toggle = true;
+ const int trigger = OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE;
[sp] Based on code abobe, I believe that OMAP...COMPARE is macro;
shouldn't we use it as is - where trigger is used in code below?
We certainly could; however, I found the above constants to make the code
far more self-documenting.
+ if (pdata == NULL) {
+ dev_err(pdev-dev, Could not find required
platform data.\n);
+ status = -ENOENT;
+ goto done;
[sp] We can simply return status from here. goto and label can be avoided.
+ }
+
+ /* Allocate memory for the driver-private PWM data and state */
+
+ pwm = kzalloc(sizeof(struct pwm_device), GFP_KERNEL);
+
+ if (pwm == NULL) {
+ dev_err(pdev-dev, Could not allocate memory.\n);
+ status = -ENOMEM;
+ goto done;
[sp] We can simply return status from here. goto and label can be avoided.
We certainly can; however, I prefer to code my functions so there's a single
exit point or block, even if it's a trivial return. See chapter 7 in
Documentation/CodingStyle.txt.
Thanks for your feedback and comments.
Regards,
Grant
--
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 v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
* Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted? Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file? The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should just work on all the boards. 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
On 11/16/10 10:43 AM, Kevin Hilman wrote: Grant Erickson maratho...@gmail.com writes: On 11/16/10 9:01 AM, Kevin Hilman wrote: Grant Erickson maratho...@gmail.com writes: This patch adds support to request and use one or more of the OMAP dual-mode timers as a generic PWM device compatible with other generic PWM drivers such as the PWM backlight or PWM beeper driver. How will this co-exist with the PWM on the twl6030 PMIC (drivers/mfd/twl6030-pwm.c.)? Both are exporting the same API. That's an excellent question. This driver started life in the 2.6.32 tree where twl6030-pwm.c didn't exist. Thanks for the heads-up. The right short-term solution is to probably change the configuration from: config HAVE_PWM to: config OMAP_PWM select HAVE_PWM and then have it conflict with TWL6030_PWM if that's enabled. And what happens when other PWM sources are added? More conflicts, of course. With the appropriate configuration change to avoid the conflict with TWL6030-PWM, it's probably better to have this driver in-tree than not. Well, Tony will make the final call here, but I disagree that this should merge in its current form. Understood. Before something like this can merge, I would rather see 1) generic PWM framework pushed along and merged 2) the dmtimer hwmod conversion finished Yes, I know it's a lot more work to fix the core/framework code before having a feature included, but having something more generic that can actually support multiple PWM sources is clearly needed. No disagreement on the long-term architectural and design goals. All good stuff. However, patches have to be submitted against the repository and branch we have today, not those we might have tomorrow. When (1) is in place in the linux-omap GIT, I am happy to work on refactoring the driver as necessary. Thanks again for your feedback and input. Best, Grant -- 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
Grant Erickson maratho...@gmail.com writes: [...] Before something like this can merge, I would rather see 1) generic PWM framework pushed along and merged 2) the dmtimer hwmod conversion finished Yes, I know it's a lot more work to fix the core/framework code before having a feature included, but having something more generic that can actually support multiple PWM sources is clearly needed. No disagreement on the long-term architectural and design goals. All good stuff. However, patches have to be submitted against the repository and branch we have today, not those we might have tomorrow. This comment is where we diverge. An alternative to waiting for the generic framework cleanup/refactor work is to contribute to it and help it along. 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 v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
Tony Lindgren t...@atomide.com writes: * Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted? Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file? The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should just work on all the boards. Personally, I'd much rather see DSS core and optional features default to being built as a module. Other than a splash screen, there's no reason DSS is needed for a minimal 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 v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
* Kevin Hilman khil...@deeprootsystems.com [101116 11:45]: Tony Lindgren t...@atomide.com writes: * Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not looked kindly at. Shouldn't they be enabled in the arch/arm/configs config file, if they are wanted? Tony, do you have opinnion on this? Should DSS features be enabled by default in the Kconfig files, or only in the board config file? The best thing would be to have DSS y if ARCH_OMAP2PLUS or similar, then have all the features built in and pass the configuration options in platform_data. That still allows disabling certain features with Kconfig if needed for memory consumption etc. But the omap2plus_defconfig should just work on all the boards. Personally, I'd much rather see DSS core and optional features default to being built as a module. Other than a splash screen, there's no reason DSS is needed for a minimal boot. Sure a module would be even better. My point is that the selection of all the features should be enabled by default and the board options come from platform_data. 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] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
* Kevin Hilman khil...@deeprootsystems.com [101116 11:43]: Grant Erickson maratho...@gmail.com writes: [...] Before something like this can merge, I would rather see 1) generic PWM framework pushed along and merged 2) the dmtimer hwmod conversion finished Yes, I know it's a lot more work to fix the core/framework code before having a feature included, but having something more generic that can actually support multiple PWM sources is clearly needed. No disagreement on the long-term architectural and design goals. All good stuff. However, patches have to be submitted against the repository and branch we have today, not those we might have tomorrow. This comment is where we diverge. An alternative to waiting for the generic framework cleanup/refactor work is to contribute to it and help it along. Yeah I agree, with Kevin. We should not export any more omap specific functions in arch/arm/*omap*/ as they always lead into maintenance nightmares later on. We still have several merge cycles of work just to get rid of the existing exported functions. 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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
* Nishanth Menon n...@ti.com [101115 16:43]:
Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon n...@ti.com wrote:
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ?
Unless I'm wrong, this means that if the opp3xxx_data.h file is
included in two different C files, the structures will be present twice.
The intent here - DONT DO precisely THAT!
As far as I could see, most of the kernel instantiate structure in C
files instead.
The intent here though was that opp3xx.h and opp4xx.h are private to
just opp.c to prevent misuse elsewhere. hmm.. thinking a bit,
find drivers/ -iname *.c|xargs grep #include| grep -v \.h
shows numerous examples of .c files being included in c files. I
dont have an issue of renaming these headers as .c file instead (I
had carried them over as .h from old implementation, but we can
change it), main point being, I just dont want folks mucking around
and hacking stuff with the defines.
What usually works best is to have common opp.c, then have opp34xx.c
that has initcall that registers the data in opp.c.
That leaves out if cpu_is_omapxxx else if stuff in opp.c and then
adding support for new omaps is just a matter of doing opp.c.
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 v3 1/3] omap: opp: add OMAP3 OPP table data and common init
* Kevin Hilman khil...@deeprootsystems.com [101116 08:06]: Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here: http://marc.info/?l=linux-omapm=127507237109393w=2 Ok, if Kevin is happy with this solution, fair enough. Sorry for the noise, and thanks for your answers. Yes, I'm not a big fan of the init function called multiple times either, but I really want to minimize what board files have to do. Historically, we tend to add all the init functions to every board file, and this is getting cumbersome to understand and maintain. What we need is for common code to take care of sensible defaults for all boards, and then only boards with non-default behavior have to have custom code. Yeah. The initial comment from Thomas with data in .h file should be fixed though. 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 2/3] OMAP: use generic DPI panel driver in board files
* Bryan Wu bryan...@canonical.com [101115 20:08]: Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight control driver code which will be moved out later. Then we can use generic DPI driver for sharp_ls_panel. Signed-off-by: Bryan Wu bryan...@canonical.com --- arch/arm/mach-omap2/board-3430sdp.c | 12 +--- arch/arm/mach-omap2/board-am3517evm.c| 23 +-- arch/arm/mach-omap2/board-cm-t35.c | 23 +-- arch/arm/mach-omap2/board-devkit8000.c | 26 ++ arch/arm/mach-omap2/board-igep0020.c | 12 +--- arch/arm/mach-omap2/board-omap3beagle.c | 12 +--- arch/arm/mach-omap2/board-omap3evm.c | 12 +--- arch/arm/mach-omap2/board-omap3stalker.c | 23 +-- 8 files changed, 105 insertions(+), 38 deletions(-) Here's my ack for these changes once Tomi is happy with the series: 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
[PATCH v2 0/8] OMAP4: mux: Add the OMAP4430 ES1.0 ES2.x support
Hi Tony, Here is the version updated with your latest fixes and improvements after a small clean to fix a checkpatch issue. I added as well a patch from Dan to add __func__ in every pr__xxx calls. The series is based on mainline (2.6.37-rc1) and is available here: git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v4 Tested on SDP4430 ES1.0, ES2.0 and ES2.1 with omap2plus_defconfig. It still requires some test on OMAP3 and OMAP2. Thanks, Benoit PATCH v1 http://www.spinics.net/lists/linux-omap/msg40039.html - Add a patch from Tony to remove the partition information used only for debugfs purpose. A look up is done when needed in order to save some memory. - Add a patch from Dan, to add __func__ information during pr_xxx calls. - Add patch from Tony to fix a crash reported by Anand Gadiyar gadi...@ti.com on zoom3 https://patchwork.kernel.org/patch/325622/ RFC v2: http://www.spinics.net/lists/linux-omap/msg38995.html - Take into account Tony's proposal to store partition information in a partition structure instead of inside every pad entries. - Remove some cpu_is_xxx calls from the core code by adding a couple of flags during partition init. RFC v1: http://www.spinics.net/lists/linux-omap/msg37158.html Benoit Cousson (6): OMAP: mux: Replace printk with pr_xxx macros OMAP: mux: Add support for control module split in several partitions OMAP4: mux: Add CBL package data for OMAP4430 ES1 OMAP4: sdp4430: Select CBL package for ES1 and initialize mux OMAP4: mux: Add CBS package data for OMAP4430 ES2 OMAP4: sdp4430: Select CBS package for ES2 Dan Murphy (1): OMAP: mux: Add __func__ macro to pr_xxx macros sricharan (1): OMAP4: pandaboard: Select CBL CBS package and initialize mux arch/arm/mach-omap2/Kconfig | 10 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-4430sdp.c | 14 + arch/arm/mach-omap2/board-omap4panda.c | 16 + arch/arm/mach-omap2/board-rx51-peripherals.c | 12 +- arch/arm/mach-omap2/mux.c| 369 -- arch/arm/mach-omap2/mux.h| 83 ++- arch/arm/mach-omap2/mux2420.c| 10 +- arch/arm/mach-omap2/mux2430.c| 10 +- arch/arm/mach-omap2/mux34xx.c|9 +- arch/arm/mach-omap2/mux44xx.c| 1625 ++ arch/arm/mach-omap2/mux44xx.h| 298 + 12 files changed, 2310 insertions(+), 147 deletions(-) create mode 100644 arch/arm/mach-omap2/mux44xx.c create mode 100644 arch/arm/mach-omap2/mux44xx.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
[PATCH v2 1/8] OMAP: mux: Replace printk with pr_xxx macros
Replace all the printk(KERN_XXX... with pr_xxx macros.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/mux.c | 38 +++---
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 074536a..979e9d1 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -102,13 +102,13 @@ int __init omap_mux_init_gpio(int gpio, int val)
}
if (found == 0) {
- printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+ pr_err(mux: Could not set gpio%i\n, gpio);
return -ENODEV;
}
if (found 1) {
- printk(KERN_INFO mux: Multiple gpio paths (%d) for gpio%i\n,
- found, gpio);
+ pr_info(mux: Multiple gpio paths (%d) for gpio%i\n,
+ found, gpio);
return -EINVAL;
}
@@ -118,8 +118,8 @@ int __init omap_mux_init_gpio(int gpio, int val)
mux_mode |= OMAP_MUX_MODE3;
else
mux_mode |= OMAP_MUX_MODE4;
- printk(KERN_DEBUG mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
- gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
+ pr_debug(mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
+gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
omap_mux_write(mux_mode, gpio_mux-reg_offset);
return 0;
@@ -161,9 +161,9 @@ int __init omap_mux_init_signal(const char *muxname, int
val)
old_mode = omap_mux_read(m-reg_offset);
mux_mode = val | i;
- printk(KERN_DEBUG mux: Setting signal
- %s.%s 0x%04x - 0x%04x\n,
- m0_entry, muxname, old_mode, mux_mode);
+ pr_debug(mux: Setting signal
+%s.%s 0x%04x - 0x%04x\n,
+m0_entry, muxname, old_mode, mux_mode);
omap_mux_write(mux_mode, m-reg_offset);
found++;
}
@@ -174,12 +174,12 @@ int __init omap_mux_init_signal(const char *muxname, int
val)
return 0;
if (found 1) {
- printk(KERN_ERR mux: Multiple signal paths (%i) for %s\n,
- found, muxname);
+ pr_err(mux: Multiple signal paths (%i) for %s\n,
+ found, muxname);
return -EINVAL;
}
- printk(KERN_ERR mux: Could not set signal %s\n, muxname);
+ pr_err(mux: Could not set signal %s\n, muxname);
return -ENODEV;
}
@@ -462,8 +462,8 @@ static void __init omap_mux_package_fixup(struct omap_mux
*p,
s++;
}
if (!found)
- printk(KERN_ERR mux: Unknown entry offset 0x%x\n,
- p-reg_offset);
+ pr_err(mux: Unknown entry offset 0x%x\n,
+ p-reg_offset);
p++;
}
}
@@ -487,8 +487,8 @@ static void __init omap_mux_package_init_balls(struct
omap_ball *b,
s++;
}
if (!found)
- printk(KERN_ERR mux: Unknown ball offset 0x%x\n,
- b-reg_offset);
+ pr_err(mux: Unknown ball offset 0x%x\n,
+ b-reg_offset);
b++;
}
}
@@ -615,7 +615,7 @@ u16 omap_mux_get_gpio(int gpio)
offset = omap_mux_get_by_gpio(gpio);
if (offset == OMAP_MUX_TERMINATOR) {
- printk(KERN_ERR mux: Could not get gpio%i\n, gpio);
+ pr_err(mux: Could not get gpio%i\n, gpio);
return offset;
}
@@ -629,7 +629,7 @@ void omap_mux_set_gpio(u16 val, int gpio)
offset = omap_mux_get_by_gpio(gpio);
if (offset == OMAP_MUX_TERMINATOR) {
- printk(KERN_ERR mux: Could not set gpio%i\n, gpio);
+ pr_err(mux: Could not set gpio%i\n, gpio);
return;
}
@@ -687,7 +687,7 @@ static void __init omap_mux_init_list(struct omap_mux
*superset)
entry = omap_mux_list_add(superset);
if (!entry) {
- printk(KERN_ERR mux: Could not add entry\n);
+ pr_err(mux: Could not add entry\n);
return;
}
superset++;
@@ -738,7 +738,7 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size,
mux_phys = mux_pbase;
mux_base = ioremap(mux_pbase, mux_size);
if (!mux_base) {
[PATCH v2 2/8] OMAP: mux: Add support for control module split in several partitions
Starting on OMAP4, the pin mux configuration is located in two
different partitions of the control module (CODE_PAD and WKUP_PAD).
The first one is inside the core power domain whereas the second
one is inside the wakeup.
- Add the capability to add any number of partition during board init
time depending of Soc partitioning.
- Add some init flags as well in order to avoid explicit Soc version
check inside the mux core code.
- Add a comment with mux0 mode on top of omap_mux/board/partition
if the current mux mode is not the default one.
Thanks to Tony Lindgren t...@atomide.com for the following improvements:
- Add omap_mux_get for getting the partition data so platform level
device code can use it.
- Fix the rx51 board code to use the new API.
- Do not store the partition for each mux entry. Look up the partition
for debugfs instead.
Thanks to Dan Murphy dmur...@ti.com for testing on OMAP4 and reporting
a couple of bugs.
Thanks to Anand Gadiyar gadi...@ti.com for testing on OMAP3 zoom and
bug report.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Tested-by: Murphy Dan dmur...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 12 +-
arch/arm/mach-omap2/mux.c| 337 ++
arch/arm/mach-omap2/mux.h| 70 +-
arch/arm/mach-omap2/mux2420.c|7 +-
arch/arm/mach-omap2/mux2430.c|7 +-
arch/arm/mach-omap2/mux34xx.c|7 +-
6 files changed, 312 insertions(+), 128 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3fec4d6..3fda20d 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -293,6 +293,8 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+static struct omap_mux_partition *partition;
+
/*
* Current flows to eMMC when eMMC is off and the data lines are pulled up,
* so pull them down. N.B. we pull 8 lines because we are using 8 lines.
@@ -300,9 +302,9 @@ static struct omap_board_mux rx51_mmc2_off_mux[] = {
static void rx51_mmc2_remux(struct device *dev, int slot, int power_on)
{
if (power_on)
- omap_mux_write_array(rx51_mmc2_on_mux);
+ omap_mux_write_array(partition, rx51_mmc2_on_mux);
else
- omap_mux_write_array(rx51_mmc2_off_mux);
+ omap_mux_write_array(partition, rx51_mmc2_off_mux);
}
static struct omap2_hsmmc_info mmc[] __initdata = {
@@ -922,7 +924,11 @@ void __init rx51_peripherals_init(void)
rx51_init_wl1251();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
- omap2_hsmmc_init(mmc);
+
+ partition = omap_mux_get(core);
+ if (partition)
+ omap2_hsmmc_init(mmc);
+
platform_device_register(rx51_charger_device);
}
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 979e9d1..9221570 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -1,9 +1,9 @@
/*
* linux/arch/arm/mach-omap2/mux.c
*
- * OMAP2 and OMAP3 pin multiplexing configurations
+ * OMAP2, OMAP3 and OMAP4 pin multiplexing configurations
*
- * Copyright (C) 2004 - 2008 Texas Instruments Inc.
+ * Copyright (C) 2004 - 2010 Texas Instruments Inc.
* Copyright (C) 2003 - 2008 Nokia Corporation
*
* Written by Tony Lindgren
@@ -40,60 +40,72 @@
#define OMAP_MUX_BASE_OFFSET 0x30/* Offset from CTRL_BASE */
#define OMAP_MUX_BASE_SZ 0x5ca
-#define MUXABLE_GPIO_MODE3 BIT(0)
struct omap_mux_entry {
struct omap_mux mux;
struct list_headnode;
};
-static unsigned long mux_phys;
-static void __iomem *mux_base;
-static u8 omap_mux_flags;
+static LIST_HEAD(mux_partitions);
+static DEFINE_MUTEX(muxmode_mutex);
+
+struct omap_mux_partition *omap_mux_get(const char *name)
+{
+ struct omap_mux_partition *partition;
+
+ list_for_each_entry(partition, mux_partitions, node) {
+ if (!strcmp(name, partition-name))
+ return partition;
+ }
-u16 omap_mux_read(u16 reg)
+ return NULL;
+}
+
+u16 omap_mux_read(struct omap_mux_partition *partition, u16 reg)
{
- if (cpu_is_omap24xx())
- return __raw_readb(mux_base + reg);
+ if (partition-flags OMAP_MUX_REG_8BIT)
+ return __raw_readb(partition-base + reg);
else
- return __raw_readw(mux_base + reg);
+ return __raw_readw(partition-base + reg);
}
-void omap_mux_write(u16 val, u16 reg)
+void omap_mux_write(struct
[PATCH v2 4/8] OMAP4: sdp4430: Select CBL package for ES1 and initialize mux
Select the CBL package if SDP4430 is enabled during config.
Initialize the mux framework during the board init.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-4430sdp.c | 10 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e14c73d..7efb256 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -280,6 +280,7 @@ config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
depends on ARCH_OMAP4
+ select OMAP_PACKAGE_CBL
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..e4f1726 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -35,6 +35,7 @@
#include plat/usb.h
#include plat/mmc.h
+#include mux.h
#include hsmmc.h
#include timer-gp.h
#include control.h
@@ -505,10 +506,19 @@ static void __init omap_sfh7741prox_init(void)
}
}
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap_4430sdp_init(void)
{
int status;
+ omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] OMAP: mux: Add __func__ macro to pr_xxx macros
From: Dan Murphy dmur...@ti.com
Removed mux: and added the __func__ macro to make debugging
easier.
Signed-off-by: Dan Murphy dmur...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 30 +++---
arch/arm/mach-omap2/mux2420.c |3 ++-
arch/arm/mach-omap2/mux2430.c |3 ++-
arch/arm/mach-omap2/mux34xx.c |2 +-
arch/arm/mach-omap2/mux44xx.c |6 +++---
5 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 9221570..3d71d93 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -114,12 +114,12 @@ static int __init _omap_mux_init_gpio(struct
omap_mux_partition *partition,
}
if (found == 0) {
- pr_err(mux: Could not set gpio%i\n, gpio);
+ pr_err(%s: Could not set gpio%i\n, __func__, gpio);
return -ENODEV;
}
if (found 1) {
- pr_info(mux: Multiple gpio paths (%d) for gpio%i\n,
+ pr_info(%s: Multiple gpio paths (%d) for gpio%i\n, __func__,
found, gpio);
return -EINVAL;
}
@@ -130,7 +130,7 @@ static int __init _omap_mux_init_gpio(struct
omap_mux_partition *partition,
mux_mode |= OMAP_MUX_MODE3;
else
mux_mode |= OMAP_MUX_MODE4;
- pr_debug(mux: Setting signal %s.gpio%i 0x%04x - 0x%04x\n,
+ pr_debug(%s: Setting signal %s.gpio%i 0x%04x - 0x%04x\n, __func__,
gpio_mux-muxnames[0], gpio, old_mode, mux_mode);
omap_mux_write(partition, mux_mode, gpio_mux-reg_offset);
@@ -190,8 +190,8 @@ static int __init _omap_mux_init_signal(struct
omap_mux_partition *partition,
old_mode = omap_mux_read(partition,
m-reg_offset);
mux_mode = val | i;
- pr_debug(mux: Setting signal
-%s.%s 0x%04x - 0x%04x\n,
+ pr_debug(%s: Setting signal
+%s.%s 0x%04x - 0x%04x\n, __func__,
m0_entry, muxname, old_mode, mux_mode);
omap_mux_write(partition, mux_mode,
m-reg_offset);
@@ -204,12 +204,12 @@ static int __init _omap_mux_init_signal(struct
omap_mux_partition *partition,
return 0;
if (found 1) {
- pr_err(mux: Multiple signal paths (%i) for %s\n,
+ pr_err(%s: Multiple signal paths (%i) for %s\n, __func__,
found, muxname);
return -EINVAL;
}
- pr_err(mux: Could not set signal %s\n, muxname);
+ pr_err(%s: Could not set signal %s\n, __func__, muxname);
return -ENODEV;
}
@@ -561,7 +561,7 @@ static void __init omap_mux_package_fixup(struct omap_mux
*p,
s++;
}
if (!found)
- pr_err(mux: Unknown entry offset 0x%x\n,
+ pr_err(%s: Unknown entry offset 0x%x\n, __func__,
p-reg_offset);
p++;
}
@@ -586,7 +586,7 @@ static void __init omap_mux_package_init_balls(struct
omap_ball *b,
s++;
}
if (!found)
- pr_err(mux: Unknown ball offset 0x%x\n,
+ pr_err(%s: Unknown ball offset 0x%x\n, __func__,
b-reg_offset);
b++;
}
@@ -722,7 +722,7 @@ u16 omap_mux_get_gpio(int gpio)
}
if (!m || m-reg_offset == OMAP_MUX_TERMINATOR)
- pr_err(mux: Could not get gpio%i\n, gpio);
+ pr_err(%s: Could not get gpio%i\n, __func__, gpio);
return OMAP_MUX_TERMINATOR;
}
@@ -742,7 +742,7 @@ void omap_mux_set_gpio(u16 val, int gpio)
}
if (!m || m-reg_offset == OMAP_MUX_TERMINATOR)
- pr_err(mux: Could not set gpio%i\n, gpio);
+ pr_err(%s: Could not set gpio%i\n, __func__, gpio);
}
static struct omap_mux * __init omap_mux_list_add(
@@ -800,7 +800,7 @@ static void __init omap_mux_init_list(struct
omap_mux_partition *partition,
entry = omap_mux_list_add(partition, superset);
if (!entry) {
- pr_err(mux: Could not add entry\n);
+ pr_err(%s: Could not add entry\n, __func__);
return;
}
superset++;
@@ -862,8 +862,8 @@ int __init omap_mux_init(const char *name, u32 flags,
partition-phys = mux_pbase;
partition-base = ioremap(mux_pbase, mux_size);
if (!partition-base) {
- pr_err(mux: Could not
[PATCH v2 6/8] OMAP4: sdp4430: Select CBS package for ES2
Select the CBS package if SDP4430 is enabled during config.
Use the proper package (CBL or CBS) based on chip revision.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/board-4430sdp.c |6 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 92fea63..39229cf 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -284,6 +284,7 @@ config MACH_OMAP_4430SDP
default y
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
+ select OMAP_PACKAGE_CBS
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index e4f1726..94d989b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -517,8 +517,12 @@ static struct omap_board_mux board_mux[] __initdata = {
static void __init omap_4430sdp_init(void)
{
int status;
+ int package = OMAP_PACKAGE_CBS;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ package = OMAP_PACKAGE_CBL;
+ omap4_mux_init(board_mux, package);
- omap4_mux_init(board_mux, OMAP_PACKAGE_CBL);
omap4_i2c_init();
omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] OMAP4: mux: Add CBS package data for OMAP4430 ES2
Please note that the full muxmodes are re-defined for ES2 instead
of using the subset. There are 81 differences among 204 pins.
The subset fixup will have to iterate over the whole list for each
subset entry, which can lead to an important number of iteration.
On the other hand, it will take much more memory at boot time.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/Kconfig |3 +
arch/arm/mach-omap2/mux.h |1 +
arch/arm/mach-omap2/mux44xx.c | 741 -
arch/arm/mach-omap2/mux44xx.h | 21 ++
4 files changed, 758 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7efb256..92fea63 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -88,6 +88,9 @@ config OMAP_PACKAGE_CBP
config OMAP_PACKAGE_CBL
bool
+config OMAP_PACKAGE_CBS
+ bool
+
comment OMAP Board Type
depends on ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 7aca779..79076d6 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -62,6 +62,7 @@
/* Flags for omapX_mux_init */
#define OMAP_PACKAGE_MASK 0x
+#define OMAP_PACKAGE_CBS 8 /* 547-pin 0.40 0.40 */
#define OMAP_PACKAGE_CBL 7 /* 547-pin 0.40 0.40 */
#define OMAP_PACKAGE_CBP 6 /* 515-pin 0.40 0.50 */
#define OMAP_PACKAGE_CUS 5 /* 423-pin 0.65 */
diff --git a/arch/arm/mach-omap2/mux44xx.c b/arch/arm/mach-omap2/mux44xx.c
index 5e9d60a..80335f3 100644
--- a/arch/arm/mach-omap2/mux44xx.c
+++ b/arch/arm/mach-omap2/mux44xx.c
@@ -48,7 +48,7 @@
}
/*
- * Superset of all mux modes for omap4
+ * Superset of all mux modes for omap4 ES1.0
*/
static struct omap_mux __initdata omap4_core_muxmodes[] = {
_OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
@@ -755,6 +755,724 @@ struct omap_ball __initdata omap4_core_cbl_ball[] = {
#endif
/*
+ * Superset of all mux modes for omap4 ES2.0
+ */
+static struct omap_mux __initdata omap4_es2_core_muxmodes[] = {
+ _OMAP4_MUXENTRY(GPMC_AD0, 0, gpmc_ad0, sdmmc2_dat0, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD1, 0, gpmc_ad1, sdmmc2_dat1, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD2, 0, gpmc_ad2, sdmmc2_dat2, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD3, 0, gpmc_ad3, sdmmc2_dat3, NULL, NULL,
+ NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD4, 0, gpmc_ad4, sdmmc2_dat4,
+ sdmmc2_dir_dat0, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD5, 0, gpmc_ad5, sdmmc2_dat5,
+ sdmmc2_dir_dat1, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD6, 0, gpmc_ad6, sdmmc2_dat6,
+ sdmmc2_dir_cmd, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD7, 0, gpmc_ad7, sdmmc2_dat7,
+ sdmmc2_clk_fdbk, NULL, NULL, NULL, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD8, 32, gpmc_ad8, kpd_row0, c2c_data15,
+ gpio_32, NULL, sdmmc1_dat0, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD9, 33, gpmc_ad9, kpd_row1, c2c_data14,
+ gpio_33, NULL, sdmmc1_dat1, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD10, 34, gpmc_ad10, kpd_row2, c2c_data13,
+ gpio_34, NULL, sdmmc1_dat2, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD11, 35, gpmc_ad11, kpd_row3, c2c_data12,
+ gpio_35, NULL, sdmmc1_dat3, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD12, 36, gpmc_ad12, kpd_col0, c2c_data11,
+ gpio_36, NULL, sdmmc1_dat4, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD13, 37, gpmc_ad13, kpd_col1, c2c_data10,
+ gpio_37, NULL, sdmmc1_dat5, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD14, 38, gpmc_ad14, kpd_col2, c2c_data9,
+ gpio_38, NULL, sdmmc1_dat6, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_AD15, 39, gpmc_ad15, kpd_col3, c2c_data8,
+ gpio_39, NULL, sdmmc1_dat7, NULL, NULL),
+ _OMAP4_MUXENTRY(GPMC_A16, 40, gpmc_a16, kpd_row4, c2c_datain0,
+ gpio_40, venc_656_data0, NULL, NULL, safe_mode),
+ _OMAP4_MUXENTRY(GPMC_A17, 41, gpmc_a17, kpd_row5, c2c_datain1,
+ gpio_41, venc_656_data1, NULL, NULL, safe_mode),
+ _OMAP4_MUXENTRY(GPMC_A18, 42, gpmc_a18, kpd_row6, c2c_datain2,
+ gpio_42, venc_656_data2, NULL, NULL, safe_mode),
+ _OMAP4_MUXENTRY(GPMC_A19, 43, gpmc_a19, kpd_row7, c2c_datain3,
+ gpio_43, venc_656_data3, NULL,
[PATCH v2 7/8] OMAP4: pandaboard: Select CBL CBS package and initialize mux
From: sricharan r.sricha...@ti.com
The mux framework allows the change of pad configuration by drivers
when needed. Prior to this the mux framework has to be initialised
with all the mux parameters specific to the board. The mux init is
already present in the board file for SDP. Adding the mux init
for panda boards.
Signed-off-by: sricharan r.sricha...@ti.com
Acked-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig|2 ++
arch/arm/mach-omap2/board-omap4panda.c | 16
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 39229cf..186d270 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -290,6 +290,8 @@ config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
default y
depends on ARCH_OMAP4
+ select OMAP_PACKAGE_CBL
+ select OMAP_PACKAGE_CBS
config OMAP3_EMU
bool OMAP3 debugging peripherals
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1ecd0a6..801f814 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -40,6 +40,7 @@
#include hsmmc.h
#include control.h
+#include mux.h
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET62
@@ -368,8 +369,23 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux NULL
+#endif
+
static void __init omap4_panda_init(void)
{
+ int package = OMAP_PACKAGE_CBS;
+
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ package = OMAP_PACKAGE_CBL;
+ omap4_mux_init(board_mux, package);
+
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
omap_serial_init();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Tony Lindgren had written, on 11/16/2010 02:35 PM, the following:
* Nishanth Menon n...@ti.com [101115 16:43]:
Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following:
Hello,
On Mon, 15 Nov 2010 13:27:39 -0600
Nishanth Menon n...@ti.com wrote:
+++ b/arch/arm/mach-omap2/opp3xxx_data.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
Do we really want to have structure definitions in an header file ?
Unless I'm wrong, this means that if the opp3xxx_data.h file is
included in two different C files, the structures will be present twice.
The intent here - DONT DO precisely THAT!
As far as I could see, most of the kernel instantiate structure in C
files instead.
The intent here though was that opp3xx.h and opp4xx.h are private to
just opp.c to prevent misuse elsewhere. hmm.. thinking a bit,
find drivers/ -iname *.c|xargs grep #include| grep -v \.h
shows numerous examples of .c files being included in c files. I
dont have an issue of renaming these headers as .c file instead (I
had carried them over as .h from old implementation, but we can
change it), main point being, I just dont want folks mucking around
and hacking stuff with the defines.
What usually works best is to have common opp.c, then have opp34xx.c
that has initcall that registers the data in opp.c.
That leaves out if cpu_is_omapxxx else if stuff in opp.c and then
adding support for new omaps is just a matter of doing opp.c.
Series rev4 already posted here:
http://marc.info/?l=linux-omapm=128993367212640w=2
I believe I have taken care of the comments there - do let me know if I
screwed anything up here..
--
Regards,
Nishanth Menon
--
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] OMAP1: drop AMS_DELTA_FIQ config option
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [101105 18:48]: This patches removes a config option that was used to select a FIQ handler to be build for Amstrad Delta, as required by the on-board serio interface driver. Not having any problem reports received since it was introduced in 2.6.35, the FIQ handler can now be built and initialized by default, thus reqiring no extra config option. Thanks, I'll queue this for 2.6.38 merge window. 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 v5] OMAP: AM3517/05: Add craneboard support
* srin...@mistralsolutions.com srin...@mistralsolutions.com [101109 06:23]: From: Srinath srin...@mistralsolutions.com Craneboard is a hardware development platform based on the Sitara AM3517 ARM Cortex - A8 microprocessor device. This is a low cost reference design. This patch adds basic board file. Detailed support will follow in subsequent patches. Queueing this for 2.6.38 merge window. 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] omap3: feature: fix OMAP3_IVA_MASK
* Nishanth Menon n...@ti.com [101105 17:29]: From: Arno Steffen arno.stef...@googlemail.com OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT Signed-off-by: Arno Steffen arno.stef...@googlemail.com --- Sending on behalf of Arno - he pointed at the change and everything except for the patch ;) Reported here: http://marc.info/?l=linux-omapm=128896969832702w=2 Hmm, until we have an official verbal-patch-to-unified-diff translator, I guess the right thing to do here is to make it be: From: Nishanth Menon n...@ti.com OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT Reported-by: Arno Steffen arno.stef...@googlemail.com Signed-off-by: Nishanth Menon n...@ti.com Can you please repost or confirm that's OK for you? Tony arch/arm/mach-omap2/control.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index b6c6b7c..5325297 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -309,7 +309,7 @@ #define FEAT_SGX_NONE 2 #define OMAP3_IVA_SHIFT 12 -#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT) +#define OMAP3_IVA_MASK (1 OMAP3_IVA_SHIFT) #define FEAT_IVA0 #define FEAT_IVA_NONE 1 -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.38] omap: McBSP: Fix potential memory leak in omap_mcbsp_remove
* Jarkko Nikula jhnik...@gmail.com [101103 02:15]: Function omap_mcbsp_probe allocates struct omap_mcbsp *mcbsp but it is not freed in omap_mcbsp_remove. Fix this, remove unneeded structure cleanups and clk_disable calls since they are not needed here. This is not problem currently but becomes if the mcbsp driver is ever modularized. Queuing this for 2.6.38 merge window. 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 ] McBSP:Make the free variable update more readable
* Jarkko Nikula jhnik...@gmail.com [101103 03:09]: On Wed, 3 Nov 2010 15:28:57 +0530 shubhrajy...@ti.com wrote: From: Shubhrajyoti D shubhrajy...@ti.com Using true/false instead of 1/0 to update the free variable. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- arch/arm/plat-omap/mcbsp.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) Acked-by: Jarkko Nikula jhnik...@gmail.com Next time, please also Cc linux-arm-kernel mailing list for your arch/arm/*omap*/ touching patches. Otherwise I have to repost before merging, which is not nice. Anyways, queuing this for 2.6.38 merge window and will repost to linux-arm-kernel along with other misc patches at some point. 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: [PATCHv3 1/1] omap: Ptr isr_reg tracked as NULL was dereferenced
* Evgeny Kuznetsov ext-eugeny.kuznet...@nokia.com [101108 00:35]: From: Evgeny Kuznetsov ext-eugeny.kuznet...@nokia.com Value of isr_reg pointer is depend on configuration and GPIO method. Potentially it may have NULL value and it is dereferenced later in code. Warning and exit from function are added in this case. Thanks, queueing this for 2.6.38 merge window. 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: BeagleBoard not resuming from uart with latest pm-core ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello Govindraj, On Mon, 15 Nov 2010 19:24:05 +0530 Govindraj govindraj...@gmail.com wrote: Can you check if you have below two patches in the kernel you have? http://www.spinics.net/lists/linux-serial/msg02684.html http://www.spinics.net/lists/linux-serial/msg02683.html If not there can you check applying these two patch I have both of these patches in my kernel (I'm running the latest pm-core from Kevin's repository). Hmm, using pm-core, I can hit full-chip retention in suspend on my Beagle C4. However, upgrading to a recent x-loader and u-boot, I can reproduce the problem. The problem is an old one that seems to have resurfaced. Namely, u-boot leaves the MUSB block in a state that prevents it from idling, and thus prevents CORE from hitting RET. I have a series of hacks for this in the PM branch (see my pm-otg-reset branch) that fixes the problem, but is not clean. This will work until the omap_hwmod conversion for MUSB is done. One of the perks we get from omap_hwmod is that a reset is done for each hwmod ensuring that any (mis)configuration of the bootloader is cleared and the HW is in a known default state. 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
[PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #7)
There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset introduces a generic panel DPI driver, remove 3 panel drivers and enable generic panel DPI driver in board files. And it is based on 2.6.37-rc2. Building with omap2plus_defconfig is successful. Keep sharp_ls_panel, since it contains blacklight control code which will be moved out later. Bryan Wu (3): OMAP: DSS2: Add generic DPI panel display driver OMAP: use generic DPI panel driver in board files OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers arch/arm/mach-omap2/board-3430sdp.c| 12 +- arch/arm/mach-omap2/board-am3517evm.c | 23 +- arch/arm/mach-omap2/board-cm-t35.c | 23 +- arch/arm/mach-omap2/board-devkit8000.c | 26 +- arch/arm/mach-omap2/board-igep0020.c | 12 +- arch/arm/mach-omap2/board-omap3beagle.c| 12 +- arch/arm/mach-omap2/board-omap3evm.c | 12 +- arch/arm/mach-omap2/board-omap3stalker.c | 23 +- .../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++ drivers/video/omap2/displays/Kconfig | 22 +- drivers/video/omap2/displays/Makefile |4 +- drivers/video/omap2/displays/panel-generic-dpi.c | 348 drivers/video/omap2/displays/panel-generic.c | 174 -- .../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 - .../video/omap2/displays/panel-toppoly-tdo35s.c| 164 - 15 files changed, 497 insertions(+), 560 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c delete mode 100644 drivers/video/omap2/displays/panel-generic.c delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver
Generic DPI panel driver includes the driver and 4 similar panel
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.
With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
.../arm/plat-omap/include/plat/panel-generic-dpi.h | 37 ++
drivers/video/omap2/displays/Kconfig |8 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-generic-dpi.c | 348
4 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include display.h
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+ const char *name;
+ int (*platform_enable)(struct omap_dss_device *dssdev);
+ void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
menu OMAP2/3 Display Device Drivers
depends on OMAP2_DSS
+config PANEL_GENERIC_DPI
+tristate Generic DPI Panel
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
config PANEL_GENERIC
tristate Generic Panel
help
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..1f208e3
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,348 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu bryan...@canonical.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/slab.h
+
+#include plat/panel-generic-dpi.h
+
+struct panel_config {
+ struct omap_video_timings timings;
+
+ int acbi; /* ac-bias pin transitions per interrupt */
+ /* Unit: line clocks */
+ int acb;/* ac-bias pin frequency */
+
+
[PATCH 2/3] OMAP: use generic DPI panel driver in board files
Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use generic DPI
driver for sharp_ls_panel.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-omap2/board-3430sdp.c | 12 +---
arch/arm/mach-omap2/board-am3517evm.c| 23 +--
arch/arm/mach-omap2/board-cm-t35.c | 23 +--
arch/arm/mach-omap2/board-devkit8000.c | 26 ++
arch/arm/mach-omap2/board-igep0020.c | 12 +---
arch/arm/mach-omap2/board-omap3beagle.c | 12 +---
arch/arm/mach-omap2/board-omap3evm.c | 12 +---
arch/arm/mach-omap2/board-omap3stalker.c | 23 +--
8 files changed, 105 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..1ca0156 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -38,6 +38,7 @@
#include plat/dma.h
#include plat/gpmc.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/gpmc-smc91x.h
@@ -270,13 +271,18 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable = sdp3430_panel_disable_lcd,
};
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= sdp3430_panel_enable_dvi,
+ .platform_disable = sdp3430_panel_disable_dvi,
+};
+
static struct omap_dss_device sdp3430_dvi_device = {
.name = dvi,
- .driver_name= generic_panel,
.type = OMAP_DISPLAY_TYPE_DPI,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= sdp3430_panel_enable_dvi,
- .platform_disable = sdp3430_panel_disable_dvi,
};
static struct omap_dss_device sdp3430_tv_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..851683f 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
#include plat/common.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include mux.h
#include control.h
@@ -303,13 +304,18 @@ static void am3517_evm_panel_disable_lcd(struct
omap_dss_device *dssdev)
lcd_enabled = 0;
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = sharp_lq,
+ .platform_enable= am3517_evm_panel_enable_lcd,
+ .platform_disable = am3517_evm_panel_disable_lcd,
+};
+
static struct omap_dss_device am3517_evm_lcd_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = lcd,
- .driver_name= sharp_lq_panel,
+ .driver_name= generic_dpi_panel,
+ .data = lcd_panel,
.phy.dpi.data_lines = 16,
- .platform_enable= am3517_evm_panel_enable_lcd,
- .platform_disable = am3517_evm_panel_disable_lcd,
};
static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -346,13 +352,18 @@ static void am3517_evm_panel_disable_dvi(struct
omap_dss_device *dssdev)
dvi_enabled = 0;
}
+static struct panel_generic_dpi_data dvi_panel = {
+ .name = generic,
+ .platform_enable= am3517_evm_panel_enable_dvi,
+ .platform_disable = am3517_evm_panel_disable_dvi,
+};
+
static struct omap_dss_device am3517_evm_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
- .driver_name= generic_panel,
+ .driver_name= generic_dpi_panel,
+ .data = dvi_panel,
.phy.dpi.data_lines = 24,
- .platform_enable= am3517_evm_panel_enable_dvi,
- .platform_disable = am3517_evm_panel_disable_dvi,
};
static struct omap_dss_device *am3517_evm_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..e91c986 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -46,6 +46,7 @@
#include plat/gpmc.h
#include plat/usb.h
#include plat/display.h
+#include plat/panel-generic-dpi.h
#include plat/mcspi.h
#include mach/hardware.h
@@ -351,22 +352,32 @@ static void cm_t35_panel_disable_tv(struct
omap_dss_device *dssdev)
{
}
+static struct panel_generic_dpi_data lcd_panel = {
+ .name = toppoly_tdo35s,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
static struct omap_dss_device cm_t35_lcd_device = {
.name
[PATCH 3/3] OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers
Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/omap2/displays/Kconfig | 18 --
drivers/video/omap2/displays/Makefile |3 -
drivers/video/omap2/displays/panel-generic.c | 174
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 165 ---
.../video/omap2/displays/panel-toppoly-tdo35s.c| 164 --
5 files changed, 0 insertions(+), 524 deletions(-)
delete mode 100644 drivers/video/omap2/displays/panel-generic.c
delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index cb3e339..9c09afd 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -9,12 +9,6 @@ config PANEL_GENERIC_DPI
Supports LCD Panel used in TI SDP3430 and EVM boards,
OMAP3517 EVM boards and CM-T35.
-config PANEL_GENERIC
-tristate Generic Panel
-help
- Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
-
config PANEL_SHARP_LS037V7DW01
tristate Sharp LS037V7DW01 LCD Panel
depends on OMAP2_DSS
@@ -22,24 +16,12 @@ config PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
-config PANEL_SHARP_LQ043T1DG01
-tristate Sharp LQ043T1DG01 LCD Panel
-depends on OMAP2_DSS
-help
- LCD Panel used in TI's OMAP3517 EVM boards
-
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
help
Taal DSI command mode panel from TPO.
-config PANEL_TOPPOLY_TDO35S
-tristate Toppoly TDO35S LCD Panel support
-depends on OMAP2_DSS
-help
- LCD Panel used in CM-T35
-
config PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on OMAP2_DSS SPI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 022058c..3bebe4d 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,9 +1,6 @@
obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
-obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
-obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-generic.c
b/drivers/video/omap2/displays/panel-generic.c
deleted file mode 100644
index 395a68d..000
--- a/drivers/video/omap2/displays/panel-generic.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * Generic panel support
- *
- * Copyright (C) 2008 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@nokia.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.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see http://www.gnu.org/licenses/.
- */
-
-#include linux/module.h
-#include linux/delay.h
-
-#include plat/display.h
-
-static struct omap_video_timings generic_panel_timings = {
- /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
- .x_res = 640,
- .y_res = 480,
- .pixel_clock= 23500,
- .hfp= 48,
- .hsw= 32,
- .hbp= 80,
- .vfp= 3,
- .vsw= 4,
- .vbp= 7,
-};
-
-static int generic_panel_power_on(struct omap_dss_device *dssdev)
-{
- int r;
-
- if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE)
- return 0;
-
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
-
- if (dssdev-platform_enable) {
- r = dssdev-platform_enable(dssdev);
- if (r)
- goto err1;
- }
-
- return 0;
-err1:
- omapdss_dpi_display_disable(dssdev);
-err0:
- return r;
-}
-
-static void generic_panel_power_off(struct omap_dss_device *dssdev)
-{
- if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
-
- if (dssdev-platform_disable)
- dssdev-platform_disable(dssdev);
-
-
