Re: [PATCH 1/2] AM35x: musb: fix compilation error
On Tue, Nov 30, 2010 at 10:30:10AM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [101122 02:12]: Hi, On Mon, Nov 22, 2010 at 02:22:40PM +0530, Ajay Kumar Gupta wrote: Fixes compilation error as control.h APIs are not available to drivers/usb/musb/am35x.c file. Earlier it was getting included from plat/control.h but now moved to new location by another pacth. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com Tony ? Do you ack the usage of that header ? NAK. Drivers should not mess with the control registers directly. Instead, the following should be done in the platform init code: $ grep -r omap_ctrl_read drivers/usb drivers/usb/musb/am35x.c: devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2) drivers/usb/musb/am35x.c: devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); drivers/usb/musb/am35x.c: u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: sw_reset = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); drivers/usb/musb/am35x.c: lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); You can pass a function pointer like board_set_power or simila in platform_data. That was my feeling too. Anand, care to update ?!? -- 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 v5] OMAP2+: PM: omap device: API's for handling mstandby mode
On Wed, Nov 24, 2010 at 4:24 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
Certain errata in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
release no standby mode and sets it to smart standby or no
standby˝ depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata:
1. Erratum ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Erratum ID: i541
sDMA FIFO draining does not finish. Applicable to all omap2+ except
omap4.
3. Erratum ID:i88
The sDMA to be put in no mstandby mode before disabling the channel
after completing the data transfer operation.
Applicable only for OMAP3430 ES1.0
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v3: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
v4: added mutex changes
v5: typo fixes for errata and erratum
arch/arm/mach-omap2/omap_hwmod.c | 43 -
arch/arm/plat-omap/include/plat/omap_device.h | 2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 4 +-
arch/arm/plat-omap/omap_device.c | 64
+
4 files changed, 111 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..de78441 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,48 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod
*oh, u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+ sf = oh-class-sysc-sysc_flags;
+
+ if (sf SYSC_HAS_MIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ }
+ retval = _set_master_standbymode(oh, idlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
+/**
* omap_hwmod_register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2116,4 +2158,3 @@ int omap_hwmod_for_each_by_class(const char *classname,
return ret;
}
-
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..4fbf7c1 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -116,6 +116,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7eaa8ed..c7ff65a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -354,7 +354,7 @@ struct omap_hwmod_omap4_prcm {
*
* HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring
Re: [PATCH 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
Hi, Nishanth Menon One more question. Do we need to implement the same thing in bootloader? I.e. Do we need to disable L2 prior invalidating L2 for OMAP3630 1st boot up? On Tue, Nov 30, 2010 at 10:18 PM, Nishanth Menon n...@ti.com wrote: TAO HU had written, on 11/30/2010 12:03 AM, the following: What would happen without this patch? L2 data corruption after back from OFF mode? I believe yes. -- Regards, Nishanth Menon -- Best Regards Hu Tao -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: PM debug: fix wake-on-timer debugfs dependency
Wakeup-on-timer code does not have/need debugfs dependency. Move
the function out of debugfs ifdef.
Fixes compile error when CONFIG_DEBUG_FS is disabled but PM debug is
enabled.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Applies to Tony's omap-fixes branch, targeted for .37-rc.
Apologies for duplicates, original had wrong address for linux-omap ML
arch/arm/mach-omap2/pm-debug.c | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 5e81517..a8afb61 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -161,6 +161,23 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
printk(KERN_INFO %-20s: 0x%08x\n, regs[i].name, regs[i].val);
}
+void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
+{
+ u32 tick_rate, cycles;
+
+ if (!seconds !milliseconds)
+ return;
+
+ tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
+ cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
+ omap_dm_timer_stop(gptimer_wakeup);
+ omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
+
+ pr_info(PM: Resume timer in %u.%03u secs
+(%d ticks at %d ticks/sec.)\n,
+ seconds, milliseconds, cycles, tick_rate);
+}
+
#ifdef CONFIG_DEBUG_FS
#include linux/debugfs.h
#include linux/seq_file.h
@@ -354,23 +371,6 @@ void pm_dbg_update_time(struct powerdomain *pwrdm, int
prev)
pwrdm-timer = t;
}
-void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
-{
- u32 tick_rate, cycles;
-
- if (!seconds !milliseconds)
- return;
-
- tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
- cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
- omap_dm_timer_stop(gptimer_wakeup);
- omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
-
- pr_info(PM: Resume timer in %u.%03u secs
-(%d ticks at %d ticks/sec.)\n,
- seconds, milliseconds, cycles, tick_rate);
-}
-
static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
{
struct seq_file *s = (struct seq_file *)user;
--
1.7.2.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
[PATCH] OMAP: DSS2: Adding check_timings and set_timings for panel-taal
From: Mayuresh Janorkar ma...@ti.com
This patch would add two APIs for panel-taal:
check_timings and set_timings.
These are required by omapfb in case we wish to set default mode through
bootargs.
e.g.: omapfb.mode=lcd:640x480-16 (display device:width X height - bits per
pixel)
omapfb_set_def_mode function in omapfb-main.c essentially needs these functions
otherwise it would return -EINVAL and default mode sent through bootargs
would be ignored.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index e1c765d..e29c308 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -476,6 +476,29 @@ static void taal_get_timings(struct omap_dss_device
*dssdev,
*timings = dssdev-panel.timings;
}
+static void taal_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+ dssdev-panel.timings.x_res = timings-x_res;
+ dssdev-panel.timings.y_res = timings-y_res;
+}
+
+static int taal_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+ if (!timings || timings-x_res != dssdev-panel.timings.x_res ||
+ timings-y_res != dssdev-panel.timings.y_res)
+ return -EINVAL;
+
+ return 0;
+}
+
static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
@@ -1563,6 +1586,8 @@ static struct omap_dss_driver taal_driver = {
.memory_read= taal_memory_read,
.get_timings= taal_get_timings,
+ .set_timings= taal_set_timings,
+ .check_timings = taal_check_timings,
.driver = {
.name = taal,
--
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] OMAP: pm.c correct the initcall for an early init.
omap2_common_pm_init is the API where generic system devices like mpu, l3 etc get initialized. This has to happen really early on during the boot and not at a later time. This is especially important with the new opp changes as these devices need to be built before the opp tables init happen. Today both are device initcalls and it works just because of the order of compilation Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 59ca03b..6ec2ee1 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -143,5 +143,5 @@ static int __init omap2_common_pm_init(void) return 0; } -device_initcall(omap2_common_pm_init); +postcore_initcall(omap2_common_pm_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 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
+ Govindraj
Hi Partha,
On 12/1/2010 8:14 AM, Basak, Partha wrote:
From: Cousson, Benoit
Sent: Tuesday, November 30, 2010 9:33 PM
Hi Kishon,
Sorry, for the delay.
On 11/22/2010 4:59 PM, ABRAHAM, KISHON VIJAY wrote:
Resending the mail in plain text format..
On Mon, Nov 22, 2010 at 9:20 PM, ABRAHAM, KISHON VIJAYkis...@ti.com
wrote:
On Mon, Oct 11, 2010 at 11:48 AM, ABRAHAM, KISHON
VIJAYkis...@ti.com wrote:
On Friday 08 October 2010 01:12 PM, Cousson, Benoit wrote:
Hi Kishon,
On 10/5/2010 6:37 PM, ABRAHAM, KISHON VIJAY wrote:
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also
SYSCONFIG
register has to be set with smart idle or no idle depending on
the
dma op mode (threshold or element sync). For doing these
operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG
register
directly.
OK, it looks like we don't have the choice... But for the
implementation, please discussed with Manju on that, He is doing
the
similar thing for the smartstandby issue on SDMA.
OK.
Looks like we have a problem when we write an API similar to
the one written
by Manju (omap_hwmod_set_master_standbymode()) [1]. In the
case of McBSP,
I have to modify omap_hwmod_set_slave_idlemode() (which is
already existing),
to include something like
+if (sf SYSC_HAS_SIDLEMODE) {
+if (idlemode)
+idlemode = HWMOD_IDLEMODE_NO;
+else
+idlemode = (oh-flags
HWMOD_SWSUP_SIDLE) ?
+HWMOD_IDLEMODE_NO :
HWMOD_IDLEMODE_SMART;
+}
How to you enable HWMOD_IDLEMODE_FORCE mode in that case?
Then an API like omap_device_require_no_idle() and
omap_device_release_no_idle()
would be written similar to omap_device_require_no_mstandby
and
omap_device_release_no_mstandby() (see [1]) that calls
omap_hwmod_set_slave_idlemode() with true/false. Passing true
to
omap_hwmod_set_slave_idlemode() will write SIDLE bits with
HWMOD_IDLEMODE_NO and false to it will write
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART depending on
HWMOD_SWSUP_SIDLE to SIDLE bits.
This works fine for McBSP since only two modes come to play
here
(HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART).
But omap_hwmod_set_slave_idlemode() API is used by UART
(serial.c Please refer [2]) which writes SIDLE bits to
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART/ and
HWMOD_IDLEMODE_FORCE.
That code should not be there. It was a temporary hacks that should be
replaced eventually with a clean omap_device API like the one you are
currently implementing.
There are a bunch of direct access to omap_hwmod struct that need to be
removed as well.
Modifying omap_hwmod_set_slave_idlemode() will require
1) serial.c to be modified to call functions like
'omap_device_require_no_idle(),
omap_device_release_no_idle()' and
'omap_device_require_force_idle() and
omap_device_release_force_idle()' instead of
omap_hwmod_set_slave_idlemode() which is currently
present.
Yep, you're right.
There are 2 problems associated with it
1) The first problem is having a single API like
omap_hwmod_set_slave_idlemode() to
set two different values like HWMOD_IDLEMODE_NO or
HWMOD_IDLEMODE_FORCE (intended to be called by
omap_device_require_no_idle()
and omap_device_require_force_idle() respectively).
According to the new design
omap_hwmod_set_slave_idlemode() is intended to take only
true/false as
arguments.
2) The second problem is having the release API's
(omap_device_release_no_idle() and
omap_device_release_force_idle()) to restore the
SYSCONFIG to the previous state.
Remember, this was not problem for McBSP since only two
modes were needed.
And what about 3 APIs?
omap_device_force_idle
omap_device_no_idle
omap_device_smart_idle
Want to reiterate Paul Walmsley's comments on Manju's DMA email dated 11/11/2010
snip
2. Rather than just using a single omap_device_mstandby() function call,
I'd rather see something like omap_device_require_no_standby() and
omap_device_release_no_standby(). omap_device_require_no_standby() would
force the initiator port into no-standby.
omap_device_release_no_standby() would return the initiator port
MSTANDBYMODE to whatever the state should be (this depends on whether
HWMOD_SWSUP_MSTDBY is set). I'd rather not have the drivers manage the
contents of the MSTANDBYMODE bits directly. Then you should be able to
drop _get_master_standbymode() and omap_hwmod_get_master_idlemode() also.
Can you please make
Re: [PATCH] OMAP: DSS2: Adding check_timings and set_timings for panel-taal
Mayuresh,
One minor comment below.
On Wed, Dec 1, 2010 at 16:29, Janorkar, Mayuresh ma...@ti.com wrote:
From: Mayuresh Janorkar ma...@ti.com
This patch would add two APIs for panel-taal:
check_timings and set_timings.
These are required by omapfb in case we wish to set default mode through
bootargs.
e.g.: omapfb.mode=lcd:640x480-16 (display device:width X height - bits per
pixel)
omapfb_set_def_mode function in omapfb-main.c essentially needs these
functions
otherwise it would return -EINVAL and default mode sent through bootargs
would be ignored.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index e1c765d..e29c308 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -476,6 +476,29 @@ static void taal_get_timings(struct omap_dss_device
*dssdev,
*timings = dssdev-panel.timings;
}
+static void taal_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /* TAAL panel's timing struct has only x_res and y_res
+ * other timing parameters are not set
+ */
Check multi-line comment style
+ dssdev-panel.timings.x_res = timings-x_res;
+ dssdev-panel.timings.y_res = timings-y_res;
+}
+
+static int taal_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ /* TAAL panel's timing struct has only x_res and y_res
+ * other timing parameters are not set
+ */
Ditto
+ if (!timings || timings-x_res != dssdev-panel.timings.x_res ||
+ timings-y_res != dssdev-panel.timings.y_res)
+ return -EINVAL;
+
+ return 0;
+}
+
static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
@@ -1563,6 +1586,8 @@ static struct omap_dss_driver taal_driver = {
.memory_read = taal_memory_read,
.get_timings = taal_get_timings,
+ .set_timings = taal_set_timings,
+ .check_timings = taal_check_timings,
.driver = {
.name = taal,
--
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] OMAP2+: PM: omap device: API's for handling mstandby mode
* ABRAHAM, KISHON VIJAY kis...@ti.com [2010-12-01 14:22:46 +0530]: On Wed, Nov 24, 2010 at 4:24 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Certain errata in OMAP2+ processors will require forcing master standby to no standby mode before completing on going operation. Without this, the results will be unpredictable. [...] + + oh = *od-hwmods; I Guess you are missing oh++ in the following loop. Thanks for catching this. I will fix it. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
On Wed, Dec 1, 2010 at 4:45 PM, Cousson, Benoit b-cous...@ti.com wrote:
+ Govindraj
Hi Partha,
On 12/1/2010 8:14 AM, Basak, Partha wrote:
From: Cousson, Benoit
Sent: Tuesday, November 30, 2010 9:33 PM
Hi Kishon,
Sorry, for the delay.
On 11/22/2010 4:59 PM, ABRAHAM, KISHON VIJAY wrote:
Resending the mail in plain text format..
On Mon, Nov 22, 2010 at 9:20 PM, ABRAHAM, KISHON VIJAYkis...@ti.com
wrote:
On Mon, Oct 11, 2010 at 11:48 AM, ABRAHAM, KISHON
VIJAYkis...@ti.com wrote:
On Friday 08 October 2010 01:12 PM, Cousson, Benoit wrote:
Hi Kishon,
On 10/5/2010 6:37 PM, ABRAHAM, KISHON VIJAY wrote:
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also
SYSCONFIG
register has to be set with smart idle or no idle depending on
the
dma op mode (threshold or element sync). For doing these
operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG
register
directly.
OK, it looks like we don't have the choice... But for the
implementation, please discussed with Manju on that, He is doing
the
similar thing for the smartstandby issue on SDMA.
OK.
Looks like we have a problem when we write an API similar to
the one written
by Manju (omap_hwmod_set_master_standbymode()) [1]. In the
case of McBSP,
I have to modify omap_hwmod_set_slave_idlemode() (which is
already existing),
to include something like
+ if (sf SYSC_HAS_SIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags
HWMOD_SWSUP_SIDLE) ?
+ HWMOD_IDLEMODE_NO :
HWMOD_IDLEMODE_SMART;
+ }
How to you enable HWMOD_IDLEMODE_FORCE mode in that case?
Then an API like omap_device_require_no_idle() and
omap_device_release_no_idle()
would be written similar to omap_device_require_no_mstandby
and
omap_device_release_no_mstandby() (see [1]) that calls
omap_hwmod_set_slave_idlemode() with true/false. Passing true
to
omap_hwmod_set_slave_idlemode() will write SIDLE bits with
HWMOD_IDLEMODE_NO and false to it will write
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART depending on
HWMOD_SWSUP_SIDLE to SIDLE bits.
This works fine for McBSP since only two modes come to play
here
(HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART).
But omap_hwmod_set_slave_idlemode() API is used by UART
(serial.c Please refer [2]) which writes SIDLE bits to
HWMOD_IDLEMODE_NO/HWMOD_IDLEMODE_SMART/ and
HWMOD_IDLEMODE_FORCE.
That code should not be there. It was a temporary hacks that should be
replaced eventually with a clean omap_device API like the one you are
currently implementing.
There are a bunch of direct access to omap_hwmod struct that need to be
removed as well.
Modifying omap_hwmod_set_slave_idlemode() will require
1) serial.c to be modified to call functions like
'omap_device_require_no_idle(),
omap_device_release_no_idle()' and
'omap_device_require_force_idle() and
omap_device_release_force_idle()' instead of
omap_hwmod_set_slave_idlemode() which is currently
present.
Yep, you're right.
There are 2 problems associated with it
1) The first problem is having a single API like
omap_hwmod_set_slave_idlemode() to
set two different values like HWMOD_IDLEMODE_NO or
HWMOD_IDLEMODE_FORCE (intended to be called by
omap_device_require_no_idle()
and omap_device_require_force_idle() respectively).
According to the new design
omap_hwmod_set_slave_idlemode() is intended to take only
true/false as
arguments.
2) The second problem is having the release API's
(omap_device_release_no_idle() and
omap_device_release_force_idle()) to restore the
SYSCONFIG to the previous state.
Remember, this was not problem for McBSP since only two
modes were needed.
And what about 3 APIs?
omap_device_force_idle
omap_device_no_idle
omap_device_smart_idle
Want to reiterate Paul Walmsley's comments on Manju's DMA email dated
11/11/2010
snip
2. Rather than just using a single omap_device_mstandby() function call,
I'd rather see something like omap_device_require_no_standby() and
omap_device_release_no_standby(). omap_device_require_no_standby() would
force the initiator port into no-standby.
omap_device_release_no_standby() would return the initiator port
MSTANDBYMODE to whatever the state should be (this depends on whether
HWMOD_SWSUP_MSTDBY is set). I'd rather not have the drivers manage the
contents of the MSTANDBYMODE bits
RE: [PATCH 1/2] AM35x: musb: fix compilation error
Tony ? Do you ack the usage of that header ? NAK. Drivers should not mess with the control registers directly. Instead, the following should be done in the platform init code: $ grep -r omap_ctrl_read drivers/usb drivers/usb/musb/am35x.c: devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2) drivers/usb/musb/am35x.c: devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); drivers/usb/musb/am35x.c: u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: sw_reset = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); drivers/usb/musb/am35x.c: lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); You can pass a function pointer like board_set_power or simila in platform_data. We would need control register apis for accessing USB PHY control , IPSS reset and interrupt clear register. This would require to add three different function pointer and that would mostly be custom to AM35x. Will that be acceptable from musb perspective ? -Ajay That was my feeling too. Anand, care to update ?!? -- 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 1/2] OMAP: DMA: prevent races while setting M idle mode to nostandby
On Tuesday 30 November 2010 15:23:47 Hunter Adrian (Nokia-MS/Helsinki) wrote: From 8c0f4490d93b67326ff24f6ce1c7e925b08d96b3 Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Mon, 22 Nov 2010 11:32:48 +0200 Subject: [PATCH 1/2] OMAP: DMA: prevent races while setting M idle mode to nostandby In a couple of OMAP errata cases, sDMA M idle mode must be set temporarily to nostandby. If two DMA users were to do that at the same time, a race condition would arise. Prevent that by using a spin lock and counting up/down the number of times nostandby is set/reset. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com Acked-by: Peter Ujfalusi peter.ujfal...@nokia.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 0/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion
Changes invloves: 1) Addition of hwmod data for omap2/3/4. 1) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 2) Runtime Conversion of McSPI driver Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Benoit Cousson (1): OMAP4: hwmod data: Add McSPI Charulatha V (5): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP3: clocks: Update clock domain name for mcspi fck OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (1): OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/clock3xxx_data.c |4 + arch/arm/mach-omap2/devices.c | 189 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ arch/arm/plat-omap/include/plat/mcspi.h| 11 + drivers/spi/omap2_mcspi.c | 225 +++--- 8 files changed, 1051 insertions(+), 300 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 3/7 v2] OMAP3: hwmod data: Add McSPI
From: Charulatha V ch...@ti.com
Update omap3 hwmod data file with McSPI info.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280
1 files changed, 280 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index a8bed84..a69285d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -20,6 +20,7 @@
#include plat/serial.h
#include plat/l4_3xxx.h
#include plat/i2c.h
+#include plat/mcspi.h
#include plat/omap34xx.h
#include omap_hwmod_common_data.h
@@ -45,6 +46,10 @@ static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
static struct omap_hwmod omap3xxx_i2c1_hwmod;
static struct omap_hwmod omap3xxx_i2c2_hwmod;
static struct omap_hwmod omap3xxx_i2c3_hwmod;
+static struct omap_hwmod omap34xx_mcspi1;
+static struct omap_hwmod omap34xx_mcspi2;
+static struct omap_hwmod omap34xx_mcspi3;
+static struct omap_hwmod omap34xx_mcspi4;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -739,6 +744,275 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* l4 core - mcspi1 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi1,
+ .clk= mcspi1_ick,
+ .addr = omap34xx_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi2 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi2 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi2,
+ .clk= mcspi2_ick,
+ .addr = omap34xx_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi3 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi3_addr_space[] = {
+ {
+ .pa_start = 0x480b8000,
+ .pa_end = 0x480b80ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi3 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi3,
+ .clk= mcspi3_ick,
+ .addr = omap34xx_mcspi3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi4 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi4_addr_space[] = {
+ {
+ .pa_start = 0x480ba000,
+ .pa_end = 0x480ba0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi4 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap34xx_mcspi4,
+ .clk= mcspi4_ick,
+ .addr = omap34xx_mcspi4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap34xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_mcspi_class = {
+ .name = mcspi,
+ .sysc = omap34xx_mcspi_sysc,
+ .rev = OMAP3_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap34xx_mcspi1_mpu_irqs[] = {
+ { .name = irq, .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap34xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 35 },
+ { .name = rx0, .dma_req = 36 },
+ { .name = tx1, .dma_req = 37 },
+ { .name =
[PATCH 1/7 v2] OMAP2420: hwmod data: Add McSPI
From: Charulatha V ch...@ti.com
Update the omap2420 hwmod data with the McSPI info.
Add a device attribute structure which will be used
for passing number of chipselects from hwmod data.
Add revision macros to be passed from rev field from
hwmod.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156
arch/arm/plat-omap/include/plat/mcspi.h|8 ++
2 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a1a3dd6..ee90151 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -17,6 +17,7 @@
#include plat/dma.h
#include plat/serial.h
#include plat/i2c.h
+#include plat/mcspi.h
#include plat/omap24xx.h
#include omap_hwmod_common_data.h
@@ -38,6 +39,8 @@ static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
+static struct omap_hwmod omap2420_mcspi1_hwmod;
+static struct omap_hwmod omap2420_mcspi2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -82,6 +85,42 @@ static struct omap_hwmod omap2420_uart3_hwmod;
static struct omap_hwmod omap2420_i2c1_hwmod;
static struct omap_hwmod omap2420_i2c2_hwmod;
+/* l4 core - mcspi1 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcspi1_hwmod,
+ .clk= mcspi1_ick,
+ .addr = omap2420_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core - mcspi2 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcspi2_hwmod,
+ .clk= mcspi2_ick,
+ .addr = omap2420_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.master = omap2420_l4_core_hwmod,
@@ -557,6 +596,119 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
.flags = HWMOD_16BIT_REG,
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_mcspi_class = {
+ .name = mcspi,
+ .sysc = omap2420_mcspi_sysc,
+ .rev = OMAP2_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap2420_mcspi1_mpu_irqs[] = {
+ { .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 35 }, /* DMA_SPI1_TX0 */
+ { .name = rx0, .dma_req = 36 }, /* DMA_SPI1_RX0 */
+ { .name = tx1, .dma_req = 37 }, /* DMA_SPI1_TX1 */
+ { .name = rx1, .dma_req = 38 }, /* DMA_SPI1_RX1 */
+ { .name = tx2, .dma_req = 39 }, /* DMA_SPI1_TX2 */
+ { .name = rx2, .dma_req = 40 }, /* DMA_SPI1_RX2 */
+ { .name = tx3, .dma_req = 41 }, /* DMA_SPI1_TX3 */
+ { .name = rx3, .dma_req = 42 }, /* DMA_SPI1_RX3 */
+};
+
+static struct omap_hwmod_ocp_if *omap2420_mcspi1_slaves[] = {
+ omap2420_l4_core__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap2420_mcspi1_hwmod = {
+ .name = mcspi1_hwmod,
+ .mpu_irqs = omap2420_mcspi1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcspi1_mpu_irqs),
+ .sdma_reqs = omap2420_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt =
[PATCH 4/7 v2] OMAP4: hwmod data: Add McSPI
From: Benoit Cousson b-cous...@ti.com
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267
1 files changed, 267 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 0d5c6eb..c244840 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -22,6 +22,7 @@
#include plat/omap_hwmod.h
#include plat/cpu.h
+#include plat/mcspi.h
#include omap_hwmod_common_data.h
@@ -1043,6 +1044,265 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
+ .name = mcspi,
+ .sysc = omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod omap44xx_mcspi1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
+ { .irq = 65 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 34 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 35 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 36 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 37 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 38 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 39 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 40 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 41 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi1_addrs[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480981ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - mcspi1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi1 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_mcspi1_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_mcspi1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcspi1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcspi1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
+ omap44xx_l4_per__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap44xx_mcspi1_hwmod = {
+ .name = mcspi1,
+ .class = omap44xx_mcspi_hwmod_class,
+ .mpu_irqs = omap44xx_mcspi1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_irqs),
+ .sdma_reqs = omap44xx_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_sdma_reqs),
+ .main_clk = mcspi1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mcspi1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
+ .dev_attr = omap_mcspi1_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* mcspi2 */
+static struct omap_hwmod omap44xx_mcspi2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
+ { .irq = 66 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 42 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 43 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 44 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 45 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi2_addrs[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - mcspi2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi2 = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_mcspi2_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_mcspi2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcspi2_addrs),
+
[PATCH 5/7 v2] OMAP3: clocks: Update clock domain name for mcspi fck
From: Charulatha V ch...@ti.com
Update clock3xxx_data for mcspi1-4 with appropriate clock domain name.
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d85ecd5..5c02baa 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1558,6 +1558,7 @@ static struct clk mcspi4_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI4_SHIFT,
.recalc = followparent_recalc,
+ .clkdm_name = core_l4_clkdm,
};
static struct clk mcspi3_fck = {
@@ -1567,6 +1568,7 @@ static struct clk mcspi3_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI3_SHIFT,
.recalc = followparent_recalc,
+ .clkdm_name = core_l4_clkdm,
};
static struct clk mcspi2_fck = {
@@ -1576,6 +1578,7 @@ static struct clk mcspi2_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI2_SHIFT,
.recalc = followparent_recalc,
+ .clkdm_name = core_l4_clkdm,
};
static struct clk mcspi1_fck = {
@@ -1585,6 +1588,7 @@ static struct clk mcspi1_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI1_SHIFT,
.recalc = followparent_recalc,
+ .clkdm_name = core_l4_clkdm,
};
static struct clk uart2_fck = {
--
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
[PATCH 6/7 v2] OMAP: devices: Modify McSPI device to adapt to hwmod framework
From: Charulatha V ch...@ti.com
Cleans up all base address definitions for omap_mcspi
and adapts the device registration and driver to hwmod framework.
Changes involves:
1) Removing all base address macro defines.
2) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute(number of chipselect).
3) Appending base address with pdata reg_offset for omap4 boards.
For omap4 all regs used in driver deviate with reg_offset_macros
defined with an value of 0x100. So pass this offset through pdata
and append the same to base address retrieved from hwmod data file
and we are not mapping *_HL_* regs which are not used in driver.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Reviewed-by: Partha Basak p-bas...@ti.com
---
arch/arm/mach-omap2/devices.c | 189 +++
arch/arm/plat-omap/include/plat/mcspi.h |3 +
drivers/spi/omap2_mcspi.c | 111 +-
3 files changed, 74 insertions(+), 229 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5a0c148..c576532 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/slab.h
#include mach/hardware.h
#include mach/irqs.h
@@ -279,163 +280,57 @@ static inline void omap_init_audio(void) {}
#include plat/mcspi.h
-#define OMAP2_MCSPI1_BASE 0x48098000
-#define OMAP2_MCSPI2_BASE 0x4809a000
-#define OMAP2_MCSPI3_BASE 0x480b8000
-#define OMAP2_MCSPI4_BASE 0x480ba000
-
-#define OMAP4_MCSPI1_BASE 0x48098100
-#define OMAP4_MCSPI2_BASE 0x4809a100
-#define OMAP4_MCSPI3_BASE 0x480b8100
-#define OMAP4_MCSPI4_BASE 0x480ba100
-
-static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
- .num_cs = 4,
-};
-
-static struct resource omap2_mcspi1_resources[] = {
- {
- .start = OMAP2_MCSPI1_BASE,
- .end= OMAP2_MCSPI1_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi1 = {
- .name = omap2_mcspi,
- .id = 1,
- .num_resources = ARRAY_SIZE(omap2_mcspi1_resources),
- .resource = omap2_mcspi1_resources,
- .dev= {
- .platform_data = omap2_mcspi1_config,
- },
-};
-
-static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
- .num_cs = 2,
-};
-
-static struct resource omap2_mcspi2_resources[] = {
- {
- .start = OMAP2_MCSPI2_BASE,
- .end= OMAP2_MCSPI2_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi2 = {
- .name = omap2_mcspi,
- .id = 2,
- .num_resources = ARRAY_SIZE(omap2_mcspi2_resources),
- .resource = omap2_mcspi2_resources,
- .dev= {
- .platform_data = omap2_mcspi2_config,
- },
-};
-
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
- defined(CONFIG_ARCH_OMAP4)
-static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
- .num_cs = 2,
-};
-
-static struct resource omap2_mcspi3_resources[] = {
- {
- .start = OMAP2_MCSPI3_BASE,
- .end= OMAP2_MCSPI3_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi3 = {
- .name = omap2_mcspi,
- .id = 3,
- .num_resources = ARRAY_SIZE(omap2_mcspi3_resources),
- .resource = omap2_mcspi3_resources,
- .dev= {
- .platform_data = omap2_mcspi3_config,
- },
-};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
- .num_cs = 1,
-};
-
-static struct resource omap2_mcspi4_resources[] = {
- {
- .start = OMAP2_MCSPI4_BASE,
- .end= OMAP2_MCSPI4_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi4 = {
- .name = omap2_mcspi,
- .id = 4,
- .num_resources = ARRAY_SIZE(omap2_mcspi4_resources),
- .resource = omap2_mcspi4_resources,
- .dev= {
- .platform_data = omap2_mcspi4_config,
+struct omap_device_pm_latency omap_mcspi_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+
[PATCH 7/7 v2] OMAP: runtime: McSPI driver runtime conversion
McSPI runtime conversion.
Changes involves:
1) remove clock framework apis to use runtime framework apis.
2) context restore from runtime resume which is a callback for get_sync.
3) Remove SYSCONFIG(sysc) register handling
(a) Remove context save and restore of sysc reg and remove soft reset
done from sysc reg as this will be done with hwmod framework.
(b) Also cleanup sysc reg bit macros.
4) Rename the omap2_mcspi_reset function to omap2_mcspi_master_setup
function as with hwmod changes soft reset will be done in
hwmod framework itself and use the return value from clock
enable function to return for failure scenarios.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Reviewed-by: Partha Basak p-bas...@ti.com
---
drivers/spi/omap2_mcspi.c | 120 +---
1 files changed, 46 insertions(+), 74 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index ad3811e..a1b157f 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -33,6 +33,7 @@
#include linux/clk.h
#include linux/io.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include linux/spi/spi.h
@@ -46,7 +47,6 @@
#define OMAP2_MCSPI_MAX_CTRL 4
#define OMAP2_MCSPI_REVISION 0x00
-#define OMAP2_MCSPI_SYSCONFIG 0x10
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
#define OMAP2_MCSPI_IRQENABLE 0x1c
@@ -63,13 +63,6 @@
/* per-register bitmasks: */
-#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLEBIT(4)
-#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUPBIT(2)
-#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
-#define OMAP2_MCSPI_SYSCONFIG_SOFTRESETBIT(1)
-
-#define OMAP2_MCSPI_SYSSTATUS_RESETDONEBIT(0)
-
#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
#define OMAP2_MCSPI_MODULCTRL_STESTBIT(3)
@@ -122,13 +115,12 @@ struct omap2_mcspi {
spinlock_t lock;
struct list_headmsg_queue;
struct spi_master *master;
- struct clk *ick;
- struct clk *fck;
/* Virtual base address of the controller */
void __iomem*base;
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
+ struct device *dev;
};
struct omap2_mcspi_cs {
@@ -144,7 +136,6 @@ struct omap2_mcspi_cs {
* corresponding registers are modified.
*/
struct omap2_mcspi_regs {
- u32 sysconfig;
u32 modulctrl;
u32 wakeupenable;
struct list_head cs;
@@ -268,9 +259,6 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].sysconfig);
-
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
@@ -280,20 +268,12 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
{
- clk_disable(mcspi-ick);
- clk_disable(mcspi-fck);
+ pm_runtime_put_sync(mcspi-dev);
}
static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
{
- if (clk_enable(mcspi-ick))
- return -ENODEV;
- if (clk_enable(mcspi-fck))
- return -ENODEV;
-
- omap2_mcspi_restore_ctx(mcspi);
-
- return 0;
+ return pm_runtime_get_sync(mcspi-dev);
}
static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
@@ -819,8 +799,9 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return ret;
}
- if (omap2_mcspi_enable_clocks(mcspi))
- return -ENODEV;
+ ret = omap2_mcspi_enable_clocks(mcspi);
+ if (ret 0)
+ return ret;
ret = omap2_mcspi_setup_transfer(spi, NULL);
omap2_mcspi_disable_clocks(mcspi);
@@ -863,10 +844,11 @@ static void omap2_mcspi_work(struct work_struct *work)
struct omap2_mcspi *mcspi;
mcspi = container_of(work, struct omap2_mcspi, work);
- spin_lock_irq(mcspi-lock);
- if (omap2_mcspi_enable_clocks(mcspi))
- goto out;
+ if (omap2_mcspi_enable_clocks(mcspi) 0)
+ return;
+
+ spin_lock_irq(mcspi-lock);
/* We only enable one channel at a time -- the one whose message is
* at the head of the queue -- although this controller would gladly
@@ -979,10 +961,9 @@ static void omap2_mcspi_work(struct work_struct *work)
spin_lock_irq(mcspi-lock);
}
-
Re: [PATCH 1/3] Backlight: driver for Sharp LS037V7DW01 panel on OMAP machine
On Tue, Nov 30, 2010 at 9:09 PM, Janorkar, Mayuresh ma...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Bryan Wu
Sent: Tuesday, November 30, 2010 5:38 PM
To: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; Gadiyar, Anand; rpur...@rpsys.net
Subject: [PATCH 1/3] Backlight: driver for Sharp LS037V7DW01 panel on OMAP
machine
This driver is split from drivers/video/backlight/sharp_ls037v7dw01.c
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/video/backlight/Kconfig | 10 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/sharp_ls037v7dw01.c | 144
+++
3 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/backlight/sharp_ls037v7dw01.c
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig
index e54a337..46b2415 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -307,6 +307,16 @@ config BACKLIGHT_PCF50633
If you have a backlight driven by a NXP PCF50633 MFD, say Y here
to
enable its driver.
+config BACKLIGHT_SHARP_LS037V7DW01
+ tristate Backlight driver for SHARP LS037V7DW01 Panel
+ depends on PANEL_GENERIC_DPI
+ help
+ If you are using Sharp LS037V7DW01 LCD panel, say Y here to enable
this driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sharp_ls037v7dw01.
+
+
[Mayuresh]: Please do not introduce extra new lines.
No problem, I will remove this for next try.
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 44c0f81..c756f49 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -35,4 +35,5 @@ obj-$(CONFIG_BACKLIGHT_ADP5520) += adp5520_bl.o
obj-$(CONFIG_BACKLIGHT_ADP8860) += adp8860_bl.o
obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
+obj-$(CONFIG_BACKLIGHT_SHARP_LS037V7DW01) += sharp_ls037v7dw01.o
diff --git a/drivers/video/backlight/sharp_ls037v7dw01.c
b/drivers/video/backlight/sharp_ls037v7dw01.c
new file mode 100644
index 000..e90595e
--- /dev/null
+++ b/drivers/video/backlight/sharp_ls037v7dw01.c
@@ -0,0 +1,144 @@
+/*
+ * Backlight driver for Sharp LS037V7DW01
+ *
+ * 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/device.h
+#include linux/backlight.h
+#include linux/fb.h
+#include linux/err.h
+
+/* This OMAP platform header file is required by this driver */
+#include plat/display.h
+
+static int sharp_ls_bl_update_status(struct backlight_device *bl)
+{
+ struct omap_dss_device *dssdev = bl_get_data(bl);
+ int level;
+
+ if (!dssdev-set_backlight)
+ return -EINVAL;
+
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ level = bl-props.brightness;
+ else
+ level = 0;
+
+ return dssdev-set_backlight(dssdev, level);
+}
+
+static int sharp_ls_bl_get_brightness(struct backlight_device *bl)
+{
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ return bl-props.brightness;
+
+ return 0;
+}
+
+static const struct backlight_ops sharp_ls_bl_ops = {
+ .get_brightness = sharp_ls_bl_get_brightness,
+ .update_status = sharp_ls_bl_update_status,
+};
+
+static int __devinit sharp_ls_bl_probe(struct platform_device *pdev)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+ struct omap_dss_device *dssdev = pdev-dev.platform_data;
+
+ if (!dssdev)
+ return -EINVAL;
+
+ memset(props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = dssdev-max_backlight_level;
+
+ bl = backlight_device_register(sharp-ls-bl, dssdev-dev, dssdev,
+
RE: [PATCH] OMAP PM: Optimize cpufreq transition latency
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Turquette, Mike Sent: Wednesday, December 01, 2010 1:20 AM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP PM: Optimize cpufreq transition latency On Thu, Nov 25, 2010 at 7:38 AM, Vishwanath BS vishwanath...@ti.com wrote: Currently cpufreq transition latency value does not really reflect the actual OMAP OPP transition delay. This patch has the actual latency value. I did profile the DVFS latency on OMAP3430, OMAP3630 and OMAP4 for worstcase(MPU and Core together) and found that in none of these platforms, transiton value goes beyong 10ms. Added a buffer of 20ms to avoid too frequent ondemand timer expiry. With this change, performance of ondemand governor is improved when tested using cpufreqbench tool. Without this patch, cpufreq-bench reported ondemand performance as 40% of performance governor, and with this patch it's around 70% (using below procedure). cpufreq-bench: http://lwn.net/Articles/339862/ http://ftp.riken.go.jp/archives/Linux/suse/people/ckornacker/cpufreq-bench/ Command used for performance testing: cpufreq-bench -l 5 -s 10 -x 5 -y 10 -g ondemand -r 5 -n 5 - v Signed-off-by: Vishwanath BS vishwanath...@ti.com --- arch/arm/plat-omap/cpu-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) mode change 100644 = 100755 arch/arm/plat-omap/cpu-omap.c diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c old mode 100644 new mode 100755 index c47faf8..d3fc423 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -158,8 +158,8 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) policy-max = policy-cpuinfo.max_freq; policy-cur = omap_getspeed(0); - /* FIXME: what's the actual transition time? */ - policy-cpuinfo.transition_latency = 300 * 1000; + /* Program the actual transition time for worstcase */ + policy-cpuinfo.transition_latency = 30 * 1000; Vishwa, This is a frequent periodic timer. Does a smaller value have any affect on CPUidle wakeups? I thought this is a deferred timer and so should not affect the cpuidle thread at all. Regards Thara -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
TAO HU had written, on 12/01/2010 02:56 AM, the following: Do we need to implement the same thing in bootloader? I.e. Do we need to disable L2 prior invalidating L2 for OMAP3630 1st boot up? Though out of context for this email list (linux kernel :)), I believe it wont hurt to do this as a standard procedure. --- 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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
Tomi Valkeinen wrote: 2010/11/30 Tomi Valkeinen tomi.valkei...@nokia.com: On Tue, 2010-11-30 at 12:29 +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Paul Mundt [mailto:let...@linux-sh.org] Sent: Tuesday, November 30, 2010 12:10 PM To: Ville Syrj?l? Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux- fb...@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: snip OMAP has user writeable shadow registers and hidden real registers for display controller. The shadow registers are latched to real registers on VFP, but only if GO bit has been set. The GO bit is cleared by the HW when latching has been done. If the GO bit is set, we cannot touch the shadow registers because we don't know when the VFP will happen. That's why there's additionally a SW cache for the config, so that we don't need to block when the GO bit is up and the user wants to change the config. The driver flushes the SW config to real registers in VSYNC interrupt handler. Does the driver flush the config to real register directly not a shadow register in VSYNC ISR? Does it mean display controller use the config flushed to the real register from the VSYNC ? I don't know OMAP in detail. But as I know other SoCs also work like it. Can Go bit is cleared by SW ? And does each overlay(FB) have its own Go bit ? If Go bit can be cleared by SW, how do you think about the following scheme ? When user wants to change the config, clear the Go bit although Go bit has been already set. And set the config shadow register and then re-set the go bit. It can make one Vsync delay for the first user who has wanted to change the config. But it can reduce the delay for the second user. And WAITFORGO can be removed. BTW as I know, Android also uses WAITFORVSYNC for multiple buffering. snip -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html BRs, -- 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: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
Jonghun Han jonghun79@gmail.com writes: Tomi Valkeinen wrote: 2010/11/30 Tomi Valkeinen tomi.valkei...@nokia.com: On Tue, 2010-11-30 at 12:29 +0530, ext Hiremath, Vaibhav wrote: -Original Message- From: Paul Mundt [mailto:let...@linux-sh.org] Sent: Tuesday, November 30, 2010 12:10 PM To: Ville Syrj?l? Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux- fb...@vger.kernel.org Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: snip OMAP has user writeable shadow registers and hidden real registers for display controller. The shadow registers are latched to real registers on VFP, but only if GO bit has been set. The GO bit is cleared by the HW when latching has been done. If the GO bit is set, we cannot touch the shadow registers because we don't know when the VFP will happen. That's why there's additionally a SW cache for the config, so that we don't need to block when the GO bit is up and the user wants to change the config. The driver flushes the SW config to real registers in VSYNC interrupt handler. Does the driver flush the config to real register directly not a shadow register in VSYNC ISR? Does it mean display controller use the config flushed to the real register from the VSYNC ? The hardware latches the shadow registers to the active registers at start of VFP. I don't know OMAP in detail. But as I know other SoCs also work like it. Can Go bit is cleared by SW? No. And does each overlay(FB) have its own Go bit? No. There is one GO bit per video output, i.e. one each for LCD and TV. -- Måns Rullgård m...@mansr.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 v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, October 29, 2010 9:08 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
VDD1.
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
index 6f85f75..241fac5 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -350,6 +350,23 @@ static struct omap_volt_data
omap44xx_vdd_core_volt_data[] = {
{.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
0x16},
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 120, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 127, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 135, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
Vishwa
+
/* By default VPFORCEUPDATE is the chosen method of voltage scaling
*/
static bool voltscale_vpforceupdate = true;
@@ -574,6 +591,8 @@ static void __init
omap3_vdd_data_configure(struct omap_vdd_info *vdd)
vdd-volt_data = omap34xx_vdd1_volt_data;
vdd-volt_data_count =
ARRAY_SIZE(omap34xx_vdd1_volt_data);
+ vdd-dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd-nr_dep_vdd =
ARRAY_SIZE(omap34xx_vdd1_dep_info);
}
vdd-vp_reg.tranxdone_status =
OMAP3430_VP1_TRANXDONE_ST_MASK;
--
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 v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, October 29, 2010 9:08 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
VDD1.
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
index 6f85f75..241fac5 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -350,6 +350,23 @@ static struct omap_volt_data
omap44xx_vdd_core_volt_data[] = {
{.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
0x16},
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 120, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 127, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 135, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
Vishwa
+
/* By default VPFORCEUPDATE is the chosen method of voltage scaling
*/
static bool voltscale_vpforceupdate = true;
@@ -574,6 +591,8 @@ static void __init
omap3_vdd_data_configure(struct omap_vdd_info *vdd)
vdd-volt_data = omap34xx_vdd1_volt_data;
vdd-volt_data_count =
ARRAY_SIZE(omap34xx_vdd1_volt_data);
+ vdd-dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd-nr_dep_vdd =
ARRAY_SIZE(omap34xx_vdd1_dep_info);
}
vdd-vp_reg.tranxdone_status =
OMAP3430_VP1_TRANXDONE_ST_MASK;
--
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 v2 13/14] OMAP3: Add voltage dependency table for VDD1.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath
Sent: Wednesday, December 01, 2010 9:01 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com
Subject: RE: [PATCH v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, October 29, 2010 9:08 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
VDD1.
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
index 6f85f75..241fac5 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -350,6 +350,23 @@ static struct omap_volt_data
omap44xx_vdd_core_volt_data[] = {
{.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
0x16},
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 120, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 127, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 135, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
I think you have already given these comments on the list. Any ways I am
incorporating them.
Regards
Thara
Vishwa
+
/* By default VPFORCEUPDATE is the chosen method of voltage scaling
*/
static bool voltscale_vpforceupdate = true;
@@ -574,6 +591,8 @@ static void __init
omap3_vdd_data_configure(struct omap_vdd_info *vdd)
vdd-volt_data = omap34xx_vdd1_volt_data;
vdd-volt_data_count =
ARRAY_SIZE(omap34xx_vdd1_volt_data);
+ vdd-dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd-nr_dep_vdd =
ARRAY_SIZE(omap34xx_vdd1_dep_info);
}
vdd-vp_reg.tranxdone_status =
OMAP3430_VP1_TRANXDONE_ST_MASK;
--
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
--
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: Introduce Backlight driver for Sharp LS037V7DW01 LCD panel
Hi, On Tue, 2010-11-30 at 20:07 +0800, ext Bryan Wu wrote: After instroducing generic DPI panel driver for OMAP DSS2 system, we need to split out backlight driver from Sharp LS037V7DW01 panel driver before we move to the generic DPI panel driver. This patchset introcuded backlight driver and cleanup the old Sharp LS037V7DW01 panel driver related code. It's built on mainline 2.6.37-rc4 Bryan Wu (3): Backlight: driver for Sharp LS037V7DW01 panel on OMAP machine OMAP: move Sharp LS LCD panel device to generic DPI panel driver and new backlight driver OMAP: DSS2: remove Sharp LS037V7DW01 panel driver I don't think this is quite the right direction. All the backlight driver does is call a function in the board file. It's not really a sharp ls backlight driver, but rather generic one. I'm not even sure if it needs the dssdev pointer. This kind of backlight is, in a sense, totally separate component from the panel itself. All they have in common is that they are packaged in the same physical display module, and they usually share the same connector. I have seen three kinds of backlights on OMAP devices: - on/off GPIO (like on 3430 SDP) - PWM based (zoom seems to have this) - Panel controlled (Taal-panel. Also PWM based, but OMAP doesn't see that) The first two could (should?) be totally separate backlights from the panel itself. For those, a generic backlight driver could perhaps work. The third one needs to be quite tied to the panel driver, and I'm not sure how easy it would be to have a separate driver for that. 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 v2 13/14] OMAP3: Add voltage dependency table for VDD1.
Thara,
-Original Message-
From: Gopinath, Thara
Sent: Friday, October 29, 2010 9:08 PM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com; khil...@deeprootsystems.com; Cousson, Benoit;
Sripathy, Vishwanath; Sawant, Anand; Gopinath, Thara
Subject: [PATCH v2 13/14] OMAP3: Add voltage dependency table for
VDD1.
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/voltage.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-
omap2/voltage.c
index 6f85f75..241fac5 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -350,6 +350,23 @@ static struct omap_volt_data
omap44xx_vdd_core_volt_data[] = {
{.volt_nominal = 110, .sr_errminlimit = 0xF9, .vp_errgain =
0x16},
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = 975000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 1075000, .dep_vdd_volt = 105},
+ {.main_vdd_volt = 120, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 127, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 135, .dep_vdd_volt = 115},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = core,
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
Dependency table for 3630 is missing. Pls add the same.
Also voltage values for 3630 does not match those on OPP table. Pls align
them.
Vishwa
+
/* By default VPFORCEUPDATE is the chosen method of voltage scaling
*/
static bool voltscale_vpforceupdate = true;
@@ -574,6 +591,8 @@ static void __init
omap3_vdd_data_configure(struct omap_vdd_info *vdd)
vdd-volt_data = omap34xx_vdd1_volt_data;
vdd-volt_data_count =
ARRAY_SIZE(omap34xx_vdd1_volt_data);
+ vdd-dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd-nr_dep_vdd =
ARRAY_SIZE(omap34xx_vdd1_dep_info);
}
vdd-vp_reg.tranxdone_status =
OMAP3430_VP1_TRANXDONE_ST_MASK;
--
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 v5 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi, On Mon, 2010-11-22 at 12:53 +0530, 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 dss_recheck_connections() called in dss_driver_probe() to set the correct manager to the corresponding omap_dss_device. The interface drivers (dsi.c, sdi.c etc) now call dispc functions with dssdev-manager-id as a parameter to specify the DISPC channel. 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() This patch combines two separate things: 1) the new channel-field + related changes (dss_recheck_connections), and 2) converting dispc functions to accept channel as a parameter. Generally about the whole patch set, I think this is starting to look ok. But two things, which are cosmetical: - I wouldn't mind a bit more verbose commit descriptions. Of course it's easy to say write better descriptions, and I don't have any direct advice for this. However, remember that the -patch won't be in the git log, so all important information should be available also from the patch descriptions. - The files are getting quite crowded with code that checks for the channel and then do the work with bits/irqs depending on the channel. This makes the code a bit difficult to read. I don't have any clear ideas right now how to make it clearer, but some methods to generalize these kinds of functions would be nice. But this is not so important for the time being, and we can improve it later. 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
UART RX wakeup from sleep not working
Hi, I'm having trouble getting the UART wakeup from sleep via activity on the RX pin working. Assumptions (using UART3) 1. Using Arago Linux 2.6.32 2. OMAP3730 is in sleep mode via echo 1 /mnt/dbg/pm_debug/sleep_while_idle 3. The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1. 4. The UARTi.IER_REG[4] SLEEP_MODE bit to 1 5. The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1 6. The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1 7. The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1 Expectations When a character arrives on the RX pin of UART3 when in sleep mode, the OMAP3730 exits sleep mode immediately via a RX_CTS_DSR_WAKE_UP interrupt. Problem The interrupt does happen but only after the UART clocks have been enabled. The OMAP3730 seems to exit sleep mode only when the UART clocks are re-enabled via omap_uart_enable_clocks() in arch/arm/mach-omap2/serial.c Any help greatly appreciated. Rick -- 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] AM35xx: Craneboard: Add USB EHCI support
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
History:
http://marc.info/?l=linux-omapw=2r=1s=Craneboard%3A+Add+USB+EHCI+supportq=t
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 40 +++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 13ead33..6fd5dfe 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -28,8 +28,13 @@
#include plat/board.h
#include plat/common.h
+#include plat/usb.h
#include mux.h
+#include control.h
+
+#define GPIO_USB_POWER 35
+#define GPIO_USB_NRESET38
/* Board initialization */
static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
@@ -53,10 +58,45 @@ static void __init am3517_crane_init_irq(void)
omap_gpio_init();
}
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = GPIO_USB_NRESET,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init am3517_crane_init(void)
{
+ int ret;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ omap_mux_init_gpio(GPIO_USB_POWER, OMAP_PIN_OUTPUT);
+
+ ret = gpio_request(GPIO_USB_POWER, usb_ehci_enable);
+ if (ret 0) {
+ pr_err(Cannot request GPIO %d\n, GPIO_USB_POWER);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_USB_POWER, 1);
+ if (ret 0)
+ goto err;
+
+ omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
+ return;
+
+err:
+ gpio_free(GPIO_USB_POWER);
+ pr_err(Unable to initialize EHCI power\n);
+ return;
}
MACHINE_START(CRANEBOARD, AM3517/05 CRANEBOARD)
--
1.7.1.226.g770c5
--
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
How to use a dummy regulator
Hi, I'm not sure how the dummy regulator framework works. Is there a simple example that closely corresponds to the following hardware setup: a. OMAP 3530 MMC2 SDIO ports connected to a Murata TI WL1271 wlan module chipset. b. Murata TI WL1271 wlan module chipset powered externally by an 1.8 Volt power supply from the board. Elvis Dowson -- 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: How to use a dummy regulator
On Dec 1, 2010, at 9:32 PM, Elvis Dowson wrote: I'm not sure how the dummy regulator framework works. Is there a simple example that closely corresponds to the following hardware setup: a. OMAP 3530 MMC2 SDIO ports connected to a Murata TI WL1271 wlan module chipset. b. Murata TI WL1271 wlan module chipset powered externally by an 1.8 Volt power supply from the board. Missed the main 3.3v power supply, the 1.8V is the reference voltage. Here is the configuration: a. OMAP 3530 MMC2 SDIO ports connected to a Murata TI WL1271 wlan module chipset. b. Murata TI WL1271 wlan module chipset connected to a 1.8 Volt VIO reference voltage. c. Murata TI WL1271 wlan module chipset powered externally by a 3.3 Volt power supply. How would I set this up in the linux-2.6.32 and linux-2.6.36 kernel versions? I recall that for the newer versions it is necessary to setup a dummy regulator, but I'm not clear on the differences or the reason why. Elvis Dowson -- 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] arm: mach-omap2: remove NULL board_mux from board files
If CONFIG_OMAP_MUX is not enabled, we can define board_mux in the header
file instead of forcing every single board to define it.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/board-2430sdp.c|2 --
arch/arm/mach-omap2/board-3430sdp.c|2 --
arch/arm/mach-omap2/board-3630sdp.c|2 --
arch/arm/mach-omap2/board-am3517evm.c |2 --
arch/arm/mach-omap2/board-apollon.c|2 --
arch/arm/mach-omap2/board-h4.c |2 --
arch/arm/mach-omap2/board-igep0020.c |2 --
arch/arm/mach-omap2/board-igep0030.c |2 --
arch/arm/mach-omap2/board-ldp.c|2 --
arch/arm/mach-omap2/board-n8x0.c |2 --
arch/arm/mach-omap2/board-omap3beagle.c|2 --
arch/arm/mach-omap2/board-omap3evm.c |2 --
arch/arm/mach-omap2/board-omap3logic.c |2 --
arch/arm/mach-omap2/board-omap3pandora.c |2 --
arch/arm/mach-omap2/board-omap3stalker.c |2 --
arch/arm/mach-omap2/board-omap3touchbook.c |2 --
arch/arm/mach-omap2/board-overo.c |2 --
arch/arm/mach-omap2/board-rx51.c |2 --
arch/arm/mach-omap2/board-zoom2.c |2 --
arch/arm/mach-omap2/board-zoom3.c |2 --
arch/arm/mach-omap2/mux.c |3 +++
arch/arm/mach-omap2/mux.h |2 ++
22 files changed, 5 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index b527f8d..ee7ac99 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -218,8 +218,6 @@ static struct omap_usb_config sdp2430_usb_config __initdata
= {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
static void __init omap_2430sdp_init(void)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..ad4cb26 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -663,8 +663,6 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
/*
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index bbcf580..4cd96d7 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -83,8 +83,6 @@ static void __init omap_sdp_init_irq(void)
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
/*
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..63035d8 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -442,8 +442,6 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(SAD2D_MCAD23, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 2c6db1a..b01d6e4 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -314,8 +314,6 @@ static void __init apollon_usb_init(void)
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
static void __init omap_apollon_init(void)
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 929993b..263da1d 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -321,8 +321,6 @@ static struct i2c_board_info __initdata h4_i2c_board_info[]
= {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
static void __init omap_h4_init(void)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..8093f1a 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -577,8 +577,6 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
-#else
-#define board_mux NULL
#endif
#if defined(CONFIG_LIBERTAS_SDIO) || defined(CONFIG_LIBERTAS_SDIO_MODULE)
diff --git a/arch/arm/mach-omap2/board-igep0030.c
b/arch/arm/mach-omap2/board-igep0030.c
index 22b0b25..8dc6ed3 100644
--- a/arch/arm/mach-omap2/board-igep0030.c
+++ b/arch/arm/mach-omap2/board-igep0030.c
@@ -366,8 +366,6 @@ void __init igep3_wifi_bt_init(void) {}
static struct
Re: [PATCH v8 00/11] OMAP: GPIO: Implement GPIO as platform device
* Varadarajan, Charulatha ch...@ti.com [101125 04:39]: Implement OMAP GPIO module in platform device model. OMAP2+ specific GPIO module uses hwmod FW. Tested on OMAP2430, OMAP4430, OMAP3430 SDP boards, OMAP4430 Blaze board and zoom3 board. Verified that this patch series does not break the OMAP1 build. I've boot tested this on N800 + 5912OSK. I'll apply these patches into devel-gpio branch and start merging these into linux-omap master branch and into for-next for the next merge window. I've also added one minor fix for 16xx, will post that 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
[PATCH v8 01-b/11] OMAP: GPIO: Make omap_gpio_show_rev bank specific
Otherwise GPIO init on 16xx may try to access uninitialized GPIO
bank as the MPUIO bank does not have a revision register.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1689,16 +1689,16 @@ static struct clk * gpio5_fck;
static struct clk *gpio_iclks[OMAP34XX_NR_GPIOS];
#endif
-static void __init omap_gpio_show_rev(void)
+static void __init omap_gpio_show_rev(struct gpio_bank *bank)
{
u32 rev;
- if (cpu_is_omap16xx())
- rev = __raw_readw(gpio_bank[1].base + OMAP1610_GPIO_REVISION);
+ if (cpu_is_omap16xx() !(bank-method != METHOD_MPUIO))
+ rev = __raw_readw(bank-base + OMAP1610_GPIO_REVISION);
else if (cpu_is_omap24xx() || cpu_is_omap34xx())
- rev = __raw_readl(gpio_bank[0].base + OMAP24XX_GPIO_REVISION);
+ rev = __raw_readl(bank-base + OMAP24XX_GPIO_REVISION);
else if (cpu_is_omap44xx())
- rev = __raw_readl(gpio_bank[0].base + OMAP4_GPIO_REVISION);
+ rev = __raw_readl(bank-base + OMAP4_GPIO_REVISION);
else
return;
@@ -1958,7 +1958,7 @@ static int __init _omap_gpio_init(void)
}
}
- omap_gpio_show_rev();
+ omap_gpio_show_rev(bank);
return 0;
}
--
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 v6] OMAP2+: PM: omap device: API's for handling mstandby mode
Certain errata in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
release no standby mode and sets it to smart standby or no
standby? depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata:
1. Erratum ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Erratum ID: i541
sDMA FIFO draining does not finish. Applicable to all omap2+ except
omap4.
3. Erratum ID:i88
The sDMA to be put in no mstandby mode before disabling the channel
after completing the data transfer operation.
Applicable only for OMAP3430 ES1.0
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v3: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
v4: added mutex changes
v5: typo fixes for errata and erratum
v6: fixed oh increment bug and also mutex(missing in v5)
arch/arm/mach-omap2/omap_hwmod.c | 47 +++-
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +-
arch/arm/plat-omap/omap_device.c | 60 +
4 files changed, 111 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..023bca9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,52 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
+ mutex_lock(omap_hwmod_mutex);
+
+ v = oh-_sysc_cache;
+ sf = oh-class-sysc-sysc_flags;
+
+ if (sf SYSC_HAS_MIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ }
+ retval = _set_master_standbymode(oh, idlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ mutex_unlock(omap_hwmod_mutex);
+
+ return retval;
+}
+
+/**
* omap_hwmod_register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2116,4 +2162,3 @@ int omap_hwmod_for_each_by_class(const char *classname,
return ret;
}
-
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..4fbf7c1 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -116,6 +116,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7eaa8ed..c7ff65a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -354,7 +354,7 @@ struct omap_hwmod_omap4_prcm {
*
* HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
* of idle, rather
Re: [PATCH v5 00/14] OMAP: DMA: hwmod and DMA as platform device
Hi Tony/Kevin, * G, Manjunath Kondaiah manj...@ti.com [2010-11-25 16:58:11 +0530]: Kevin, * G, Manjunath Kondaiah manj...@ti.com [2010-11-24 18:21:36 +0530]: Patch series to convert DMA library into platform driver using platform device model and adapting hwmod for omap2+. [...] Patch series applies on top of latest linux omap master branch: * git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Branch: master commit 25f7615faa843731af4eda7d05077f1c5132e1a9 Merge: 784bee8 8973a21 Author: Tony Lindgren t...@atomide.com Linux-omap rebuilt: Updated to -rc3 * It also applies cleanly on top of: * git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git Branch: pm-core commit 8bcd9727ee126dc50093e84f19dd6c118842202f Merge: 632dd87 25f7a1d Author: Kevin Hilman khil...@deeprootsystems.com Merge branch 'pm-hacks' into pm-reset * Do you have any further comments for this series? -Manjunath [...] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP: DMA: prevent races while setting M idle mode to nostandby
Hi Adrian,
* Adrian Hunter adrian.hun...@nokia.com [2010-11-30 15:23:47 +0200]:
From 8c0f4490d93b67326ff24f6ce1c7e925b08d96b3 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Mon, 22 Nov 2010 11:32:48 +0200
Subject: [PATCH 1/2] OMAP: DMA: prevent races while setting M idle mode to
nostandby
In a couple of OMAP errata cases, sDMA M idle mode must be
set temporarily to nostandby. If two DMA users were to do
that at the same time, a race condition would arise.
Prevent that by using a spin lock and counting up/down the
number of times nostandby is set/reset.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/plat-omap/dma.c | 59 ++---
1 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index a863f55..6158c99 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -139,6 +139,9 @@ static spinlock_t dma_chan_lock;
static struct omap_dma_lch *dma_chan;
static void __iomem *omap_dma_base;
+static u32 midlemode_saved;
+static int midlemode_save_cnt;
+
static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = {
INT_DMA_CH0_6, INT_DMA_CH1_7, INT_DMA_CH2_8, INT_DMA_CH3,
INT_DMA_CH4, INT_DMA_CH5, INT_1610_DMA_CH6, INT_1610_DMA_CH7,
@@ -1016,6 +1019,41 @@ void omap_start_dma(int lch)
}
EXPORT_SYMBOL(omap_start_dma);
+static void midlemode_nostandby(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(dma_chan_lock, flags);
+ if (!midlemode_save_cnt) {
+ u32 l;
+
+ midlemode_saved = dma_read(OCP_SYSCONFIG);
+ l = midlemode_saved;
+ l = ~DMA_SYSCONFIG_MIDLEMODE_MASK;
+ l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE);
+ dma_write(l, OCP_SYSCONFIG);
+ }
+ midlemode_save_cnt += 1;
+ spin_unlock_irqrestore(dma_chan_lock, flags);
The latest DMA hwmod patch series is already taken care of this
issue through the API's:
https://patchwork.kernel.org/patch/372231/
-Manjunath
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module
hiroshi.d...@nokia.com wrote: From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module Date: Mon, 25 Oct 2010 21:10:02 +0200 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Does that means you are going to send a pull request with these for .38? Fernando, is there a branch where you have all the changes needed in tidspbridge? I guess the only patch missing would be the one for linux-arm. Cheers. -- Felipe Contreras -- 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/2] AM35x: musb: fix compilation error
On Wed, 2010-12-01 at 17:38 +0530, Gupta, Ajay Kumar wrote: Tony ? Do you ack the usage of that header ? NAK. Drivers should not mess with the control registers directly. Instead, the following should be done in the platform init code: $ grep -r omap_ctrl_read drivers/usb drivers/usb/musb/am35x.c: devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2) drivers/usb/musb/am35x.c: devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); drivers/usb/musb/am35x.c: u32 devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2); drivers/usb/musb/am35x.c: sw_reset = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); drivers/usb/musb/am35x.c: lvl_intr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR); You can pass a function pointer like board_set_power or simila in platform_data. We would need control register apis for accessing USB PHY control , IPSS reset and interrupt clear register. This would require to add three different function pointer and that would mostly be custom to AM35x. Will that be acceptable from musb perspective ? why don't you add a proper otg_transceiver driver for am35x ? Is it like omap4's internal phy ? A separate block ? -- 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 v6] OMAP2+: PM: omap device: API's for handling mstandby mode
On 01/12/10 20:47, ext G, Manjunath Kondaiah wrote:
Certain errata in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
release no standby mode and sets it to smart standby or no
standby? depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata:
1. Erratum ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Erratum ID: i541
sDMA FIFO draining does not finish. Applicable to all omap2+ except
omap4.
3. Erratum ID:i88
The sDMA to be put in no mstandby mode before disabling the channel
after completing the data transfer operation.
Applicable only for OMAP3430 ES1.0
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com
Cc: Kevin Hilmankhil...@deeprootsystems.com
Cc: Paul Walmsleyp...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v3: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
v4: added mutex changes
v5: typo fixes for errata and erratum
v6: fixed oh increment bug and also mutex(missing in v5)
arch/arm/mach-omap2/omap_hwmod.c | 47 +++-
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +-
arch/arm/plat-omap/omap_device.c | 60 +
4 files changed, 111 insertions(+), 2 deletions(-)
Does not seem to handle overlapping requests to set/clear
midle mode.
Also, there is a mutex but don't these functions get called
sometimes in interrupt context?
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..023bca9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,52 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
+ mutex_lock(omap_hwmod_mutex);
+
+ v = oh-_sysc_cache;
+ sf = oh-class-sysc-sysc_flags;
+
+ if (sf SYSC_HAS_MIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ }
+ retval = _set_master_standbymode(oh, idlemode,v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ mutex_unlock(omap_hwmod_mutex);
+
+ return retval;
+}
+
+/**
* omap_hwmod_register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2116,4 +2162,3 @@ int omap_hwmod_for_each_by_class(const char *classname,
return ret;
}
-
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..4fbf7c1 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -116,6 +116,8 @@ int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7eaa8ed..c7ff65a 100644
---
Re: UART RX wakeup from sleep not working
Hello Rick, On Wed, 1 Dec 2010, Rick Bronson wrote: I'm having trouble getting the UART wakeup from sleep via activity on the RX pin working. Assumptions (using UART3) 1. Using Arago Linux 2.6.32 2. OMAP3730 is in sleep mode via echo 1 /mnt/dbg/pm_debug/sleep_while_idle 3. The UARTi.SCR_REG[4] RX_CTS_WU_EN bit is set to 1. 4. The UARTi.IER_REG[4] SLEEP_MODE bit to 1 5. The UARTi.SYSC_REG[2] ENAWAKEUP bit is set to 1 6. The UARTi.WER_REG EVENT_4_RX_ACTIVITY bit is set to 1 7. The UARTi.SSR_REG RX_CTS_DSR_WAKE_UP_STS bit is set to 1 Expectations When a character arrives on the RX pin of UART3 when in sleep mode, the OMAP3730 exits sleep mode immediately via a RX_CTS_DSR_WAKE_UP interrupt. Problem The interrupt does happen but only after the UART clocks have been enabled. The OMAP3730 seems to exit sleep mode only when the UART clocks are re-enabled via omap_uart_enable_clocks() in arch/arm/mach-omap2/serial.c If the OMAP is in full-chip retention, the UART's asynchronous wakeup mechanism won't work, which appears to be what you're trying to use. That will only work when PER is fully powered, as far as I know. You'll need to use the IO chain wakeup feature instead. My guess is that you need to make sure that your UART input pads have the WAKEUPENABLE bits set in the CONTROL_PADCONF registers. I think that should do it. - 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 5/7 v2] OMAP3: clocks: Update clock domain name for mcspi fck
Hello Govindraj On Wed, 1 Dec 2010, Govindraj.R wrote: From: Charulatha V ch...@ti.com Update clock3xxx_data for mcspi1-4 with appropriate clock domain name. Signed-off-by: Charulatha V ch...@ti.com Looks like this is missing your Signed-off-by:. Also, please submit this patch separately and I will take it as part of the clock patches for 2.6.38. regards - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module
On Wed, Dec 1, 2010 at 1:27 PM, Felipe Contreras felipe.contre...@nokia.com wrote: hiroshi.d...@nokia.com wrote: From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCHv5 0/4] omap: iovmm - fixes for iovmm module Date: Mon, 25 Oct 2010 21:10:02 +0200 Version 5: * Changes in iommu: create new api to set valid da range - Change range variables to platform data structure. Acked-by: Hiroshi DOYU hiroshi.d...@nokia.com Does that means you are going to send a pull request with these for .38? Fernando, is there a branch where you have all the changes needed in tidspbridge? No, I dont have that branch. I guess the only patch missing would be the one for linux-arm. Yes, after merging them, the only missing is the SG chain patch. Regards, Fernando. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/8] TILER-DMM: DMM-PAT driver for TI TILER
On Wed, Dec 1, 2010 at 12:04 AM, Varadarajan, Charulatha ch...@ti.com wrote: David, + if (!oh) + goto error; + + data-base = oh-_mpu_rt_va; not required. Make use of platform_get APIs in probe to extract the base, dma and irq info using pdev. Not sure about using platform_get APIs. I think one has to use omap_hwmod_get_mpu_rt_va to get the address, which internally returns oh-_mpu_rt_va. omap_hwmod_get_mpu_rt_va was added so that the individual drivers can avoid doing the ioremap. check the discussion regarding this. http://www.spinics.net/lists/linux-omap/msg33048.html Thank you, Best regards, Hari Kanigeri -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/8] TILER-DMM: DMM-PAT driver for TI TILER
On Wed, Dec 1, 2010 at 8:10 PM, Kanigeri, Hari h-kanige...@ti.com wrote: On Wed, Dec 1, 2010 at 12:04 AM, Varadarajan, Charulatha ch...@ti.com wrote: David, + if (!oh) + goto error; + + data-base = oh-_mpu_rt_va; not required. Make use of platform_get APIs in probe to extract the base, dma and irq info using pdev. Not sure about using platform_get APIs. I think one has to use omap_hwmod_get_mpu_rt_va to get the address, which internally returns oh-_mpu_rt_va. small correction... omap_device_get_rt_va and not omap_hwmod_get_mpu_rt_va. Thank you, Best regards, Hari Kanigeri -- 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 00/14] OMAP: DMA: hwmod and DMA as platform device
Hi, * G, Manjunath Kondaiah manj...@ti.com [101201 10:53]: Do you have any further comments for this series? I'll be looking at it on Thursday. 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 v6 0/7] nand prefetch-irq support and ecc layout chanage
On Saturday 27 November 2010 06:57:37 Ghorai, Sukumar wrote: Hello Grazvydas Charles, Would you please check this series in you setup and please update the status or any issue you observe? Hello It took a while for me to get back to this. I applied the patches but still no luck running with the HW ECC disabled. The image was written with SW ECC using UBOOT. This system is actually running on an Overo with a customised kernel. Ideally, the ECC will not change from version to version. I shall explore further... Here is a boot log: [0.00] Linux version 2.6.37-rc3-sdu-1+ (char...@charles-laptop) (gcc version 4.3.3 (GCC) ) #27 Thu Dec 2 16:43:03 NZDT 2010 [0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: Gumstix Overo [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3525 ES2.1 (l2cache iva neon isp ) [0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 [0.00] Kernel command line: console=ttyO2,115200n8 video=omapfb:vram:2M,vram:4M root=ubi0:root rw rootfstype=ubifs ubi.mtd=7 [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 256MB = 256MB total [0.00] Memory: 256664k/256664k available, 5480k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xd080 - 0xf800 ( 632 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0038000 ( 192 kB) [0.00] .text : 0xc0038000 - 0xc02c2000 (2600 kB) [0.00] .data : 0xc02c2000 - 0xc02fac80 ( 228 kB) [0.00] NR_IRQS:409 [0.00] Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz [0.00] Reprogramming SDRC clock to 331882352 Hz [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] GPMC revision 5.0 [0.00] Trying to install interrupt handler for IRQ402 [0.00] Trying to install interrupt handler for IRQ403 [0.00] Trying to install interrupt handler for IRQ404 [0.00] Trying to install interrupt handler for IRQ405 [0.00] Trying to install interrupt handler for IRQ406 [0.00] Trying to install interrupt handler for IRQ407 [0.00] Trying to install interrupt handler for IRQ408 [0.00] Trying to install type control for IRQ409 [0.00] Trying to set irq flags for IRQ409 [0.00] Could not get gpios_ick [0.00] Could not get gpios_fck [0.00] OMAP GPIO hardware version 2.5 [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696) [0.00] pid_max: default: 32768 minimum: 301 [0.00] Mount-cache hash table entries: 512 [0.00] CPU: Testing write buffer coherency: ok [0.00] regulator: core version 0.5 [0.00] regulator: dummy: [0.00] NET: Registered protocol family 16 [0.00] omap_mux_init: Add partition: #1: core, flags: 0 [0.00] Found NAND on CS0 [0.00] Registering NAND on CS0 [0.00] finished sdu_init [0.00] hw-breakpoint: debug architecture 0x4 unsupported. [0.00] OMAP DMA hardware revision 4.0 [0.010284] bio: create slab bio-0 at 0 [0.014343] omap_device: i2c_omap.1: new worst case activate latency 0: 30517 [0.014434] i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz [0.017730] twl4030: PIH (irq 7) chaining IRQs 368..375 [0.017761] twl4030: power (irq 373) chaining IRQs 376..383 [0.018432] twl4030: gpio (irq 368) chaining IRQs 384..401 [0.022277] regulator: VMMC1: 1850 -- 3150 mV at 3000 mV normal standby [0.022552] i2c_omap i2c_omap.3: bus 3 rev3.12 at 100 kHz [0.025238] Bluetooth: Core ver 2.15 [0.025512] NET: Registered protocol family 31 [0.025512] Bluetooth: HCI device and connection manager initialized [0.025543] Bluetooth: HCI socket layer initialized [0.025573] Switching to clocksource 32k_counter [0.048950] NET: Registered protocol family 2 [0.049255] IP route cache hash table entries: 2048 (order: 1,
RE: [PATCH 1/2] AM35x: musb: fix compilation error
We would need control register apis for accessing USB PHY control , IPSS reset and interrupt clear register. This would require to add three different function pointer and that would mostly be custom to AM35x. Will that be acceptable from musb perspective ? why don't you add a proper otg_transceiver driver for am35x ? Is it like omap4's internal phy ? A separate block ? AM35x PHY is built inside the ip and we need to configure it through PHY control register. Additionally we also need to access IPSS reset and Intr clear register as well which would not fit inside otg_transceiver. Ajay -- 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 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Wednesday, December 01, 2010 8:09 PM To: TAO HU Cc: TAO HU; linux-omap; Jean; Tony; Kevin; Vishwa Subject: Re: [PATCH 4/5 v2] OMAP3630: PM: Disable L2 cache while invalidating L2 cache TAO HU had written, on 12/01/2010 02:56 AM, the following: Do we need to implement the same thing in bootloader? I.e. Do we need to disable L2 prior invalidating L2 for OMAP3630 1st boot up? Though out of context for this email list (linux kernel :)), I believe it wont hurt to do this as a standard procedure. You should always invalidate the cache before enabling it. Now if at the 1st boot-up if the ROM code / boot-loader is doing this, you don't have do it. At least from kernel point of it's responsibility of boot-loaders/boot-straps to keep the caches invalidated. That's why the generic kernel don't invalidate them before enabling them. RMK has documeneted this. Read 2. Loader Checks http://www.arm.linux.org.uk/developer/noboot-checklist/ Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/8] TILER-DMM: DMM-PAT driver for TI TILER
On Thu, Dec 2, 2010 at 07:57, Kanigeri, Hari h-kanige...@ti.com wrote:
On Wed, Dec 1, 2010 at 8:10 PM, Kanigeri, Hari h-kanige...@ti.com wrote:
On Wed, Dec 1, 2010 at 12:04 AM, Varadarajan, Charulatha ch...@ti.com
wrote:
David,
+ if (!oh)
+ goto error;
+
+ data-base = oh-_mpu_rt_va;
not required. Make use of platform_get APIs in probe to extract the
base, dma and irq info using pdev.
Not sure about using platform_get APIs. I think one has to use
omap_hwmod_get_mpu_rt_va to get the address, which internally returns
oh-_mpu_rt_va.
small correction... omap_device_get_rt_va and not omap_hwmod_get_mpu_rt_va.
To get the base address irq, you need not have to use
omap_device_get_rt_va and pass it as
pdata and then use it during probe. Instead in probe, you may do
something like the following:
static int __devinit dev_probe (*pdev) {
struct resource *res;
void __iomem *base;
u16 irq;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(!res)) {
return -ENODEV;
}
base = ioremap(res-start, resource_size(res));
if (base) {
return -ENOMEM;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
return -ENODEV;
}
irq = res-start;
}
-V Charulatha
--
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 1/9] OMAP3: PM: Adding voltage driver support for OMAP3
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, November 11, 2010 12:00 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, Vishwanath; Sawant, Anand Subject: Re: [PATCH v4 1/9] OMAP3: PM: Adding voltage driver support for OMAP3 Thara Gopinath th...@ti.com writes: This patch adds voltage driver support for OMAP3. The driver allows configuring the voltage controller and voltage processors during init and exports APIs to enable/disable voltage processors, scale voltage and reset voltage. The driver also maintains the global voltage table on a per VDD basis which contains the various voltages supported by the VDD along with per voltage dependent data like smartreflex n-target value, errminlimit and voltage processor errorgain. The driver allows scaling of VDD voltages either through vc bypass method or through vp forceupdate method the choice being configurable through the board file. This patch contains code originally in linux omap pm branch smartreflex driver. Major contributors to this driver are Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley, Nishant Menon, Kevin Hilman. Signed-off-by: Thara Gopinath th...@ti.com All comments below are cut-and-paste from v3 review, and were not addressed in this update. --- arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/voltage.c | 1158 + arch/arm/plat-omap/include/plat/voltage.h | 141 3 files changed, 1301 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/voltage.c create mode 100644 arch/arm/plat-omap/include/plat/voltage.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 0b6d9af..bfdabcc 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -51,7 +51,8 @@ obj-$(CONFIG_ARCH_OMAP2) += sdrc2xxx.o ifeq ($(CONFIG_PM),y) obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o -obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o pm_bus.o +obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \ + cpuidle34xx.o pm_bus.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c new file mode 100644 index 000..5aa5109 --- /dev/null +++ b/arch/arm/mach-omap2/voltage.c @@ -0,0 +1,1158 @@ +/* + * OMAP3/OMAP4 Voltage Management Routines + * + * Author: Thara Gopinath th...@ti.com + * + * Copyright (C) 2007 Texas Instruments, Inc. + * Rajendra Nayak rna...@ti.com + * Lesly A M x0080...@ti.com + * + * Copyright (C) 2008 Nokia Corporation + * Kalle Jokiniemi + * + * Copyright (C) 2010 Texas Instruments, Inc. + * Thara Gopinath th...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/io.h +#include linux/clk.h +#include linux/err.h +#include linux/debugfs.h +#include linux/slab.h + +#include plat/common.h +#include plat/voltage.h + +#include prm-regbits-34xx.h + +#define VP_IDLE_TIMEOUT200 +#define VP_TRANXDONE_TIMEOUT 300 +#define VOLTAGE_DIR_SIZE 16 + +static struct dentry *voltage_dir; +/* PRM voltage module */ +static u32 volt_mod; There's no need for this to be a global, this should be a member of vdd_info (or the voltage domain.) That means the read/write functions will have to take an additional argument (vdd or voltdm) but that's cleaner to me. Kevin, The voltage_read and voltage_write APIs are used not only for the per vdd registers. We also access the vc registers through them and passing vdd or voltdm is not an option. Two options we have are 1. Keep the existing implementation 2. Have volt_mod/prm_mod per vdd basis in the omap_vdd_info struct. Introduce a new struct for storing vc parameters per SoC basis and have a prm_mod there also. Scrap voltage_read and voltage_write APIs and use prm_read and prm_write instead. The last step is because we do not want a voltage_read / voltage_write which looks exactly similar to prm_read/prm_write and do nothing but call into prm_read/prm_write. Do let me know your thoughts as I m in the midst of the rework. I am assuming you would prefer option 2 and proceeding :-)! Regards Thara -- 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] AM35xx: Craneboard: Add USB EHCI support
* srin...@mistralsolutions.com srin...@mistralsolutions.com [2010-12-01
22:28:50 +0530]:
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
History:
http://marc.info/?l=linux-omapw=2r=1s=Craneboard%3A+Add+USB+EHCI+supportq=t
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 40
+++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 13ead33..6fd5dfe 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -28,8 +28,13 @@
[...]
static void __init am3517_crane_init(void)
{
+ int ret;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ omap_mux_init_gpio(GPIO_USB_POWER, OMAP_PIN_OUTPUT);
This is non void function. You can consider return value for further
processing.
+
+ ret = gpio_request(GPIO_USB_POWER, usb_ehci_enable);
+ if (ret 0) {
+ pr_err(Cannot request GPIO %d\n, GPIO_USB_POWER);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_USB_POWER, 1);
+ if (ret 0)
+ goto err;
+
+ omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT);
-Ditto-
Also, why there is no gpio_request for GPIO_USB_NRESET
-Manjunath
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7 v2] OMAP3: clocks: Update clock domain name for mcspi fck
On Thu, Dec 2, 2010 at 6:31 AM, Paul Walmsley p...@pwsan.com wrote: Hello Govindraj On Wed, 1 Dec 2010, Govindraj.R wrote: From: Charulatha V ch...@ti.com Update clock3xxx_data for mcspi1-4 with appropriate clock domain name. Signed-off-by: Charulatha V ch...@ti.com Looks like this is missing your Signed-off-by:. Yes, I will add it Also, please submit this patch separately and I will take it as part of the clock patches for 2.6.38. Yes sure. Will send out as a separate patch -- Thanks, Govindraj.R regards - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- --- Regards, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Patch v3] AM35xx: Craneboard: Add USB EHCI support
Hi Manjunath,
Thanks for the review, Please find my response inline.
With Regards
Srinath
-Original Message-
From: G, Manjunath Kondaiah [mailto:manj...@ti.com]
Sent: Thursday, December 02, 2010 11:56 AM
To: srin...@mistralsolutions.com
Cc: linux-omap@vger.kernel.org; j...@ti.com; t...@atomide.com;
linux-ker...@vger.kernel.org; li...@arm.linux.org.uk;
linux-arm-ker...@lists.infradead.org; khil...@deeprootsystems.com;
n...@ti.com; nagen...@mistralsolutions.com; ume...@mistralsolutions.com
Subject: Re: [Patch v3] AM35xx: Craneboard: Add USB EHCI support
* srin...@mistralsolutions.com srin...@mistralsolutions.com [2010-12-01
22:28:50 +0530]:
From: Srinath srin...@mistralsolutions.com
AM3517/05 Craneboard has one EHCI interface on board using port1.
GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.
History:
http://marc.info/?l=linux-omapw=2r=1s=Craneboard%3A+Add+USB+EHCI+support;
q=t
Signed-off-by: Srinath srin...@mistralsolutions.com
---
arch/arm/mach-omap2/board-am3517crane.c | 40
+++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 13ead33..6fd5dfe 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -28,8 +28,13 @@
[...]
static void __init am3517_crane_init(void)
{
+ int ret;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+ /* Configure GPIO for EHCI port */
+ omap_mux_init_gpio(GPIO_USB_POWER, OMAP_PIN_OUTPUT);
This is non void function. You can consider return value for further
processing.
Srinath Sure, I will put check and resend patch
+
+ ret = gpio_request(GPIO_USB_POWER, usb_ehci_enable);
+ if (ret 0) {
+ pr_err(Cannot request GPIO %d\n, GPIO_USB_POWER);
+ return;
+ }
+
+ ret = gpio_direction_output(GPIO_USB_POWER, 1);
+ if (ret 0)
+ goto err;
+
+ omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT);
-Ditto-
Srinath Sure, I will put check and resend patch
Also, why there is no gpio_request for GPIO_USB_NRESET
Srinath This is taken care by USB driver in drivers/usb/host/ehci-omap.c
-Manjunath
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled
Hello Jean On Thu, 25 Nov 2010, Jean Pihet wrote: On Thu, Nov 25, 2010 at 6:35 PM, Paul Walmsley p...@pwsan.com wrote: On Thu, 25 Nov 2010, Jean Pihet wrote: On Thu, Nov 25, 2010 at 12:49 AM, Paul Walmsley p...@pwsan.com wrote: The console semaphore must be held while the OMAP UART devices are disabled, lest a console write cause an ARM abort (and a kernel crash) when the underlying console device is inaccessible. These crashes only occur when the console is on one of the OMAP internal serial ports. This does not fix the issue for me on Beagle (console on ttyO2). Doing: / # echo 5 /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout / # echo 5 /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout / # echo 5 /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout and waiting 5 seconds hangs the console. By the way, you write that the above situation hangs the console. Is it just the case that the console dies and the rest of the system is still alive, or does the whole system crash? The console hangs, the rest of the system still runs. Just out of curiosity, if you send a few breaks to the OMAP over serial, does that cause the console to pay attention again? CTRL-A F in minicom. - Paul
[PATCH 1/3] omap4: Add platform changes for Ambient Light sensor
From 10f5f9f918e197f4052ac66b4e4cfb4b72646878 Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Wed, 1 Dec 2010 16:28:51 +0530
Subject: [PATCH] omap4: Add platform changes for Ambient Light sensor
Register BH1780GLI Ambient light sensor, which is an I2C device
for 4430SDP board.
Signed-off-by: Hemanth V heman...@ti.com
---
BH1780GLI Driver is part of mainline kernel
arch/arm/mach-omap2/board-4430sdp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 49b5a7b..d8ef903 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -465,6 +465,9 @@ static struct i2c_board_info __initdata
sdp4430_i2c_3_boardinfo[] = {
{
I2C_BOARD_INFO(tmp105, 0x48),
},
+ {
+ I2C_BOARD_INFO(bh1780, 0x29),
+ },
};
static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
{
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] omap4: Add platform changes for PWM LED
From b90e733faa2fcbe4241dcce01c7722e77c91705f Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Wed, 1 Dec 2010 17:51:10 +0530
Subject: [PATCH] omap4: Add platform changes for PWM LED
Register TWL6030 PWM, which is used as charging LED
Signed-off-by: Hemanth V heman...@ti.com
---
TWL6030 PWM driver is part of mainline kernel
arch/arm/mach-omap2/board-4430sdp.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index d8ef903..ea56c30 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,7 @@
#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
+#include linux/leds_pwm.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -97,6 +98,28 @@ static struct gpio_led_platform_data sdp4430_led_data = {
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static struct led_pwm sdp4430_pwm_leds[] = {
+ {
+ .name = omap4:green:chrg,
+ .pwm_id = 1,
+ .max_brightness = 255,
+ .pwm_period_ns = 7812500,
+ },
+};
+
+static struct led_pwm_platform_data sdp4430_pwm_data = {
+ .num_leds = ARRAY_SIZE(sdp4430_pwm_leds),
+ .leds = sdp4430_pwm_leds,
+};
+
+static struct platform_device sdp4430_leds_pwm = {
+ .name = leds_pwm,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_pwm_data,
+ },
+};
+
static int omap_prox_activate(struct device *dev)
{
gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
@@ -204,6 +227,7 @@ static struct platform_device *sdp4430_devices[] __initdata
= {
sdp4430_lcd_device,
sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
+ sdp4430_leds_pwm,
};
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap4: Platform changes for CMA3000 Accelerometer driver
From 0ce7ea442ffbe89f563baa993669a4216b2ccffa Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Thu, 2 Dec 2010 12:44:19 +0530
Subject: [PATCH] omap4: Platform changes for CMA3000 Accelerometer driver
Update 4430SDP board file with platform data for accelerometer driver
Signed-off-by: Hemanth V heman...@ti.com
---
CMA3000 Driver is queued up for 2.6.38 merge window
arch/arm/mach-omap2/board-4430sdp.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ea56c30..c336673 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -24,6 +24,8 @@
#include linux/regulator/machine.h
#include linux/leds.h
#include linux/leds_pwm.h
+#include linux/input/cma3000.h
+#include linux/interrupt.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -45,6 +47,7 @@
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_CMA3000ACCL_GPIO 186
#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
@@ -477,6 +480,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3 = sdp4430_vaux3,
};
+static struct cma3000_platform_data cma3000_platform_data = {
+ .fuzz_x = 25,
+ .fuzz_y = 25,
+ .fuzz_z = 25,
+ .g_range= CMARANGE_8G,
+ .mode = CMAMODE_MOTDET,
+ .mdthr = 0x8,
+ .mdfftmr= 0x33,
+ .ffthr = 0x8,
+ .irqflags = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+ if (gpio_request(OMAP4_CMA3000ACCL_GPIO, Accelerometer) 0) {
+ pr_err(Accelerometer GPIO request failed\n);
+ return;
+ }
+ gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl6030, 0x48),
@@ -497,6 +521,11 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO(hmc5843, 0x1e),
},
+ {
+ I2C_BOARD_INFO(cma3000_d01, 0x1c),
+ .platform_data = cma3000_platform_data,
+ .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+ },
};
static int __init omap4_i2c_init(void)
{
@@ -531,6 +560,7 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
}
+ omap_cma3000accl_init();
}
#ifdef CONFIG_OMAP_MUX
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH 3/3] omap4: Platform changes for CMA3000 Accelerometer driver
Pl ignore the earlier patch, which seems to have rebasing issues.
Thanks
Hemanth
From 42cb400c1bd3878977bc8fd416c9c39f81bed674 Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Thu, 2 Dec 2010 12:44:19 +0530
Subject: [PATCH] omap4: Platform changes for CMA3000 Accelerometer driver
Update 4430 SDP board file with platform data for accelerometer driver
Signed-off-by: Hemanth V heman...@ti.com
---
CMA3000 Driver is queued up for 2.6.38 merge window
arch/arm/mach-omap2/board-4430sdp.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ea56c30..6bda335 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -24,6 +24,8 @@
#include linux/regulator/machine.h
#include linux/leds.h
#include linux/leds_pwm.h
+#include linux/input/cma3000.h
+#include linux/interrupt.h
#include mach/hardware.h
#include mach/omap4-common.h
@@ -45,6 +47,7 @@
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_CMA3000ACCL_GPIO 186
#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
@@ -477,6 +480,27 @@ static struct twl4030_platform_data sdp4430_twldata = {
.vaux3 = sdp4430_vaux3,
};
+static struct cma3000_platform_data cma3000_platform_data = {
+ .fuzz_x = 25,
+ .fuzz_y = 25,
+ .fuzz_z = 25,
+ .g_range= CMARANGE_8G,
+ .mode = CMAMODE_MOTDET,
+ .mdthr = 0x8,
+ .mdfftmr= 0x33,
+ .ffthr = 0x8,
+ .irqflags = IRQF_TRIGGER_HIGH,
+};
+
+static void omap_cma3000accl_init(void)
+{
+ if (gpio_request(OMAP4_CMA3000ACCL_GPIO, Accelerometer) 0) {
+ pr_err(Accelerometer GPIO request failed\n);
+ return;
+ }
+ gpio_direction_input(OMAP4_CMA3000ACCL_GPIO);
+}
+
static struct i2c_board_info __initdata sdp4430_i2c_boardinfo[] = {
{
I2C_BOARD_INFO(twl6030, 0x48),
@@ -497,6 +521,11 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
{
I2C_BOARD_INFO(hmc5843, 0x1e),
},
+ {
+ I2C_BOARD_INFO(cma3000_d01, 0x1c),
+ .platform_data = cma3000_platform_data,
+ .irq = OMAP_GPIO_IRQ(OMAP4_CMA3000ACCL_GPIO),
+ },
};
static int __init omap4_i2c_init(void)
{
@@ -570,6 +599,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_cma3000accl_init();
}
static void __init omap_4430sdp_map_io(void)
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter
Hi, Tomi Valkeinen wrote: Hi, On Mon, 2010-11-22 at 12:53 +0530, 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 dss_recheck_connections() called in dss_driver_probe() to set the correct manager to the corresponding omap_dss_device. The interface drivers (dsi.c, sdi.c etc) now call dispc functions with dssdev-manager-id as a parameter to specify the DISPC channel. 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() This patch combines two separate things: 1) the new channel-field + related changes (dss_recheck_connections), and 2) converting dispc functions to accept channel as a parameter. Generally about the whole patch set, I think this is starting to look ok. But two things, which are cosmetical: - I wouldn't mind a bit more verbose commit descriptions. Of course it's easy to say write better descriptions, and I don't have any direct advice for this. However, remember that the -patch won't be in the git log, so all important information should be available also from the patch descriptions. I will update the comments. - The files are getting quite crowded with code that checks for the channel and then do the work with bits/irqs depending on the channel. This makes the code a bit difficult to read. I don't have any clear ideas right now how to make it clearer, but some methods to generalize these kinds of functions would be nice. But this is not so important for the time being, and we can improve it later. I am assuming that you are referring to 'DISPC_IRQ_MASK_ERROR' and the registering/unregistering of irq masks in manager.c I guess we could have a dss_features function which could return the mask based on what omap it is. But this way the mask values/contents would be totally invisble in manager.c and dispc.c, one would need to check it in dss_features.c, which also isn't readable. One thing which I would like to add is that this series doesn't need to touch any board file for now. The present dss_recheck_connections() doesn't try to differentiate between LCD and DIGIT channels, it just uses 'omap_display_type' to differentiate between them. Only a panel which needs to connect to LCD2 has to do this, This method wouldn't have worked if we didn't switch to uniform use of dssdev-manager-id instead of dssdev-channel. We will need to change dss_recheck_connections() in the future to make it more uniform. Regards, Archit -- 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 v6] OMAP2+: PM: omap device: API's for handling mstandby mode
On 02/12/10 08:12, ext G, Manjunath Kondaiah wrote: * Adrian Hunteradrian.hun...@nokia.com [2010-12-01 22:16:44 +0200]: On 01/12/10 20:47, ext G, Manjunath Kondaiah wrote: Certain errata in OMAP2+ processors will require forcing master standby to no standby mode before completing on going operation. Without this, the results will be unpredictable. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these API's will support the same. One API will force the device's sysconfig mstandby mode settings to no standby and other API will release no standby mode and sets it to smart standby or no standby? depending on HWMOD_SWSUP_MSTANDBY value. These API's should be used by device drivers only incase of erratum applicable to their modules if there is no other methods to resolve. These API's are required for multiple DMA errata which require putting DMA controller in no mstandby mode before stopping dma. The applicable errata: 1. Erratum ID: i557(Applicable for omap36xx all ES versions) The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared through config port while in Standby. 2. Erratum ID: i541 sDMA FIFO draining does not finish. Applicable to all omap2+ except omap4. 3. Erratum ID:i88 The sDMA to be put in no mstandby mode before disabling the channel after completing the data transfer operation. Applicable only for OMAP3430 ES1.0 Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in omap_hwmod.h Signed-off-by: G, Manjunath Kondaiahmanj...@ti.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Paul Walmsleyp...@pwsan.com Cc: linux-arm-ker...@lists.infradead.org --- Change summary: v3: Review comments incorporated for: https://patchwork.kernel.org/patch/282212/ v4: added mutex changes v5: typo fixes for errata and erratum v6: fixed oh increment bug and also mutex(missing in v5) arch/arm/mach-omap2/omap_hwmod.c | 47 +++- arch/arm/plat-omap/include/plat/omap_device.h |2 + arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/omap_device.c | 60 + 4 files changed, 111 insertions(+), 2 deletions(-) Does not seem to handle overlapping requests to set/clear midle mode. We can have use count so that we can avoid register access during middle of operation if mstandby mode is already changed to no standby mode. Exactly Also, there is a mutex but don't these functions get called sometimes in interrupt context? I feel we should leave this to caller of these API's. The caller should make sure that, he disables interrupts if it is used in interrupt context. How does that help? It seems to me that a mutex cannot be used for this. -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
