Re: [PATCH 5/5] OMAP3: PM: Disable OTG autoidle when waking up from off-mode
Hello All, On Thu, Nov 12, 2009 at 04:40:56PM +0100, ext Gadiyar, Anand wrote: Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com OMAP3 sleep can be prevented in some cases where OTG autoidle is enabled. This patch force disables autoidle during wakeup from off-mode. See omap errata 1.164. This fix can't be done in driver level, as off-mode entry resets and enables the autoidle bit, and driver does not access the register after each off-mode entry even if it is loaded. Signed-off-by: Tero Kristo tero.kri...@nokia.com Thanks Tero for the updated changelog. Applying to PM branch reluctantly and with grumbles. I sure hope someone in TI is reporting all these ROM code issues to the ROM code team so they get appropriate fixes. Kevin Yes, rest assured we're following these up with the HW teams. This particular one should not matter on 3630, we can keep autoidle enabled all the time, I think. I've made a few tests with pm branch + rx51. Currently at: commit 1f1d16a8164d63459c1a5e155bcb9fc8a15b859e Merge: 46e0bec 5660cac Author: Kevin Hilman khil...@deeprootsystems.com Date: Wed Dec 16 16:09:47 2009 -0800 manual merge for branch pm-debug And this patch OMAP3: PM: Disable OTG autoidle when waking up from off-mode Seams to be not complete at least. It causes: # modprobe g_zero [ 28.073944] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 28.080932] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 28.088317] usb usb1: Product: MUSB HDRC host driver [ 28.093414] usb usb1: Manufacturer: Linux 2.6.32-14504-g1f1d16a musb-hcd [ 28.100250] usb usb1: SerialNumber: musb_hdrc [ 28.110565] hub 1-0:1.0: USB hub found [ 28.114715] hub 1-0:1.0: 1 port detected [ 28.119506] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060 [ 28.127288] Internal error: : 1028 [#1] [ 28.131164] last sysfs file: /sys/devices/platform/serial8250.2/sleep_timeout [ 28.138366] Modules linked in: g_zero(+) [ 28.142364] CPU: 0Not tainted (2.6.32-14504-g1f1d16a #10) [ 28.148284] PC is at musb_start+0x18/0xdc [ 28.152343] LR is at musb_hub_control+0x33c/0x454 [ 28.157104] pc : [c01b85a8]lr : [c01bc3ec]psr: 80d3 [ 28.157135] sp : cf3fbac8 ip : 001c20a8 fp : cf3fbb80 [ 28.168731] r10: cf824000 r9 : 8053 r8 : 0001 [ 28.174011] r7 : 0008 r6 : cf3fbb80 r5 : fa0ab000 r4 : cf824168 [ 28.180603] r3 : r2 : cf3923c0 r1 : 0001 r0 : cf824168 [ 28.187194] Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user [ 28.194580] Control: 10c5387d Table: 8fea4019 DAC: 0015 [ 28.200408] Process modprobe (pid: 405, stack limit = 0xcf3fa2e8) [ 28.206573] Stack: (0xcf3fbac8 to 0xcf3fc000) [ 28.210968] bac0: 2303 cf824168 cf3fbb80 c01bc3ec 2303 [ 28.219238] bae0: 0008 ce8544c0 0001 cf824000 c01a8280 cf3fbb80 [ 28.227539] bb00: cf3923c0 c026ef98 842b0152 0001 c04f1f34 0004 [ 28.235809] bb20: c026ef98 0001 cf3923c0 0006 0007 cf3fbbf4 [ 28.244079] bb40: 0024 c0071598 cf3923c0 c0071a20 cf3fbbd0 2053 cf3fbbf4 c00718d0 [ 28.252349] bb60: cf3923c0 cf3923f0 c051e63c c00701b8 cf3fbbe0 cf3fbbd0 c0a6b1b0 c00701b8 [ 28.260620] bb80: cf3fbbe0 cf3fbbd0 c0a6b1b0 03e8 ce8544c0 cf3fbbcc 03e8 [ 28.268890] bba0: ce8544c0 0001 cf3fbc2c cf3a0c00 c01a9d30 0001 cf3923c0 [ 28.277160] bbc0: 0006 0007 0001 0001 dead4ead [ 28.285430] bbe0: c0a6b1b0 c030a3fb ce8544c0 cf3fbbf4 cf3fbbf4 c00a7f60 [ 28.293731] bc00: cfeb6340 0008 0023 0001 0003 c01a9fcc [ 28.302001] bc20: c036e25c 8100 c036e25c c004f0a8 0002 cfeaf400 0005 [ 28.310272] bc40: 0010 cfeaf200 ce852f80 c01a1104 0008 0001 [ 28.318542] bc60: 03e8 cfeaf400 0005 c01a1668 40408180 cfeaf400 [ 28.326812] bc80: cfeaf400 cfeaf220 c01a21cc cf800140 00d0 cf3a0c00 cf3a0c00 [ 28.335083] bca0: ce854540 6053 cf800140 40408180 0004 cfeaf400 cfeaf220 cf3a0c00 [ 28.343353] bcc0: 0010 cfeaf200 ce852f80 c01a4de0 c0312a3e cfeb63c0 000f [ 28.351623] bce0: 1388 c0071598 cf3923c0 c026cd88 6053 cf3a0f3c c04f1da0 c00718d0 [ 28.359924] bd00: cf3a0f64 cf3a0f3c 6053 cf3a0c00 cfeaf220 cfeaf200 [ 28.368194] bd20: cf3a0c00 c04f1da0 c04f1e84 c04f1d4c cfeaf228 c01ac620 cfeaf220 [ 28.376464] bd40: c04f1da0 cfeaf000 c04f2004 c0178838 c0178968 [ 28.384735] bd60: cfeaf220 cfeaf000 c0177e30 cf8b5690 cf8b8c18 cfeaf220 cfeaf254 [ 28.393005] bd80: c0178a1c cfeaf200 cfeaf220 c0177c80
Re: Flush the D-cache during copy_user_highpage breaks compile for v7 on -rc1
On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: Hi Catalin, You may have already run into this, but if not, looks like commit 115b22474eb1905da2f606a057da345583d3 breaks compile for v7: arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing': arch/arm/mm/copypage-v6.c:51: error: implicit declaration of function '__cpuc_flush_dcache_page' Undoing that makes it work again. It's a combination of changes - my initial changes for fixing the ARMv7 DMA support went in last night, but were based on a tree older than Catalin's changes, which had already been committed. My test build didn't catch any of these - it's the usual problem that there is no way to adequately build-test the ARM kernel in a reasonable time anymore. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] OMAP3: PM: Fix OTG autoidle workaround
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch fix the OTG autoidle workaround so now
usb gadget modules can be properly loaded.
Besides it also adds a cpu check, because this hardware
but is present only in OMAP34xx chips.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |3 ++-
arch/arm/mach-omap2/usb-musb.c |9 -
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c301261..db75975 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -505,7 +505,8 @@ void omap_sram_idle(void)
* Errata 1.164 fix : OTG autoidle can prevent
* sleep
*/
- usb_musb_disable_autoidle();
+ if (cpu_is_omap34xx())
+ usb_musb_disable_autoidle();
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index bb3cee4..cbd4e45 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -81,7 +81,14 @@ static void __init usb_musb_pm_init(void)
void usb_musb_disable_autoidle(void)
{
- __raw_writel(0, otg_base + OTG_SYSCONFIG);
+ if (otg_clk) {
+ unsigned long reg;
+
+ clk_enable(otg_clk);
+ reg = __raw_readl(otg_base + OTG_SYSCONFIG);
+ __raw_writel(reg ~1, otg_base + OTG_SYSCONFIG);
+ clk_disable(otg_clk);
+ }
}
#ifdef CONFIG_USB_MUSB_SOC
--
1.6.5.7.g9ecb2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ASoC: OMAP4: Add support for McPDM
Hi, On Fri, Dec 18, 2009 at 03:23:14AM +0100, ext Candelaria Villareal, Jorge wrote: Is this because if two interrupts were set, my approach would not recognize it as one of the cases and exit without processing the interrupt? you don't have a break in your switch. your approach would go through all irq cases no matter what :-p what ? so even if you don't have a platform_device you register the driver ?? So, it would be better if I had declared a platform_device structure in .../arch/arm/plat-omap/devices.c, and register its resources (irq and memory base) in there? IMO yeah. It would look cleaner. But McBSP is the same mess so I don't know what the ALSA people will say. Jarkko Nikula probably has some ideas as he did most of the OMAP ASoC implementation. -- 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/1] OMAP3: PM: Fix OTG autoidle workaround
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch fix the OTG autoidle workaround so now
usb gadget modules can be properly loaded.
Besides it also adds a cpu check, because this hardware
but is present only in OMAP34xx chips.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |3 ++-
arch/arm/mach-omap2/usb-musb.c |9 -
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c301261..db75975 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -505,7 +505,8 @@ void omap_sram_idle(void)
* Errata 1.164 fix : OTG autoidle can prevent
* sleep
*/
- usb_musb_disable_autoidle();
+ if (cpu_is_omap34xx())
If you're doing this, could you please make it cpu_is_omap3430() only?
3630 is not affected. But cpu_is_omap34xx() will return true on 3630
as well.
- Anand
+ usb_musb_disable_autoidle();
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index bb3cee4..cbd4e45 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -81,7 +81,14 @@ static void __init usb_musb_pm_init(void)
void usb_musb_disable_autoidle(void)
{
- __raw_writel(0, otg_base + OTG_SYSCONFIG);
+ if (otg_clk) {
+ unsigned long reg;
+
+ clk_enable(otg_clk);
+ reg = __raw_readl(otg_base + OTG_SYSCONFIG);
+ __raw_writel(reg ~1, otg_base + OTG_SYSCONFIG);
+ clk_disable(otg_clk);
+ }
}
#ifdef CONFIG_USB_MUSB_SOC
--
1.6.5.7.g9ecb2
--
To unsubscribe from this list: send the line unsubscribe 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 00/10 V5] omap3: pm: introduce support for 3630 OPPs
[...]
To facilitate the ongoing discussions on OPP rework, and to have a
common base, this series is available as a branch in my linux-omap-pm
repo[1].
snip
Yes, I'm in the process cleaning that up.
Once I get some of that cleanup done, I plan to rebase your OPP V5 and
include it in the PM branch.
I tried the latest HEAD on pm-wip-opp. Looks like the cpufreq tables are not
initialized because are not initializing {mpu|dsp|l3}_opps. Looks like the
comment on the latest commit is to use OPP APIs directly. Is there any patch
currently on that direction? Otherwise in the pm-wip-opp branch cpufreq is
broken.
Thanks,
-Romit
--
To unsubscribe from this list: send the line unsubscribe 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] AM35xx: Add clock support for new modules on AM35xx
Hello Paul,
Thanks for the review comments. My replies below.
On Fri, 18-Dec-09 7:12 AM +0530, Paul Walmsley wrote:
+/* Clocks for AM35XX */
+static struct clk emac_ick = {
+.name = emac_ick,
+.ops= clkops_omap2_dflt,
Shouldn't this clock use clkops_omap2_dflt_wait (or rather, some custom
version that knows how to read the _ACK bits in IPSS_CLK_CTRL) and test
CPGMAC_VBUSP_CLK_EN_ACK? Same for the other IPSS VBUSP clocks? (I
guess
VBUSP is a synonym for interface?)
I will ad a custom clkops to address this. Do we need a find_companion
to be defined? The VBUSP clock ACK's do not depend on functional clocks
and the functional clocks themselves don't have ant ACK or status bits.
EMAC, VPFE amd MUSBOTG are initiators, but the their ACK bits are just
for the target idle status.
One of the issues on AM35xx is regarding the status indicator for new
clocks. Here 1 indicates as enabled and 0 as not ready state, similar to
24xx case but just opposite to 34xx clocks. And now we have a mix of
these two on AM35xx. In omap2_cm_wait_idlest, I do not get a per clock
granularity to decide what should be the status check for that
particular clock. One of the approach I am thinking is to define a new
clock flag (say INVERT_ENABLE_STATUS) and set it for the new AM35xx
clocks. And in omap2_module_wait_ready I will do the cpu check and flag
check on a per clock basis and determine the status that need to be
checked and pass it toomap2_module_wait_ready to check what we
want. omap2_module_wait_ready will not be doing any cpu checks as its
done today. Let me know what you think.
+static struct clk emac_fck = {
+.name = emac_fck,
+.ops= clkops_omap2_dflt,
+.clkdm_name = core_l3_clkdm,
Is this the correct clockdomain for this clock? It seems unlikely that a
50MHz functional clock would be in core_l3_clkdm. Usually these are all
interface clocks. This applies for all the other functional clocks
listed
in this file also.
Would it be OK if we just don't set clkdm_name. I am not sure whether we
can map it to any existing OMAP3 clock domains that way
+.rate = 5000,
What's the parent of this clock? Looking at TRM section 4.7.7.12 it
appears that it gets this from an off-chip source, rmii_clk? Guess
that
should probably be defined as the fixed source clock, and emac_fck should
list rmii_clk as its parent?
+.enable_reg = OMAP343X_CTRL_REGADDR(AM35XX_CONTROL_IPSS_CLK_CTRL),
+.enable_bit = AM35XX_CPGMAC_FCLK_SHIFT,
+.recalc = omap2_clksel_recalc,
This .recalc field is wrong, since there's no .clksel field defined. If
you define that parent, then this should be followparent_recalc. The
parent should have .flags = RATE_FIXED and no .recalc.
Do we really need to define an rmii_ck? Can we make emac_fck itself as
the root clock with no parent? Here is what I was thinking of. Let me
know if you see any issues with this
static struct clk emac_fck = {
.name = emac_fck,
.ops= clkops_omap2_dflt,
.flags = RATE_FIXED,
.rate = 5000,
.enable_reg = OMAP343X_CTRL_REGADDR(OMAP3517_CONTROL_IP_CLK_CTRL),
.enable_bit = OMAP3517_CPGMAC_FCLK_SHIFT,
};
+static struct clk vpfe_fck = {
+.name = vpfe_fck,
+.ops= clkops_omap2_dflt,
+.clkdm_name = core_l3_clkdm,
+.rate = 2700,
+.enable_reg = OMAP343X_CTRL_REGADDR(AM35XX_CONTROL_IPSS_CLK_CTRL),
+.enable_bit = AM35XX_VPFE_FCLK_SHIFT,
+.recalc = omap2_clksel_recalc,
This fixed rate clock isn't right, for the same reasons as described
above.
Would make it similar to emac_fck depending on what we decide.
+CLK(musb_hdrc, ick, hsotgusb_ick_am35xx, CK_AM35XX),
+CLK(musb_hdrc, fck, hsotgusb_fck_am35xx, CK_AM35XX),
+CLK(NULL, hecc_ck, hecc_ck, CK_AM35XX),
+CLK(vpfe-capture, master, vpfe_ick, CK_AM35XX),
+CLK(vpfe-capture, slave, vpfe_fck, CK_AM35XX),
+CLK(NULL, uart4_ick, uart4_ick, CK_AM35XX),
Please align the new structure entries with the previous entries.
Will do that.
- Ranjith
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/1] OMAP3: PM: Fix OTG autoidle workaround
From: Eduardo Valentin eduardo.valen...@nokia.com
This patch fix the OTG autoidle workaround so now
usb gadget modules can be properly loaded.
Besides it also adds a cpu check, because this hardware
but is present only in OMAP34xx chips.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |3 ++-
arch/arm/mach-omap2/usb-musb.c |9 -
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c301261..db75975 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -505,7 +505,8 @@ void omap_sram_idle(void)
* Errata 1.164 fix : OTG autoidle can prevent
* sleep
*/
- usb_musb_disable_autoidle();
+ if (cpu_is_omap3430())
+ usb_musb_disable_autoidle();
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index bb3cee4..cbd4e45 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -81,7 +81,14 @@ static void __init usb_musb_pm_init(void)
void usb_musb_disable_autoidle(void)
{
- __raw_writel(0, otg_base + OTG_SYSCONFIG);
+ if (otg_clk) {
+ unsigned long reg;
+
+ clk_enable(otg_clk);
+ reg = __raw_readl(otg_base + OTG_SYSCONFIG);
+ __raw_writel(reg ~1, otg_base + OTG_SYSCONFIG);
+ clk_disable(otg_clk);
+ }
}
#ifdef CONFIG_USB_MUSB_SOC
--
1.6.5.7.g9ecb2
--
To unsubscribe from this list: send the line unsubscribe 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: [alsa-devel] [PATCH 2/3] ASoC: OMAP4: Add support for McPDM
On Fri, Dec 18, 2009 at 11:51:30AM +0100, ext Mark Brown wrote: On Thu, Dec 17, 2009 at 10:28:21PM +0200, Felipe Balbi wrote: On Thu, Dec 17, 2009 at 08:40:32PM +0100, ext Candelaria Villareal, Jorge wrote: +config SND_OMAP_SOC_MCPDM + tristate look at how SND_OMAP_SOC_N810 is done, can't you follow that ? put some description ad help ? This is fine - DAI drivers should be selected by machine drivers rather than by users since they are useless without the machine drivers. This means that they shouldn't have a description. +EXPORT_SYMBOL(omap_mcpdm_start); +EXPORT_SYMBOL(omap_mcpdm_stop); +EXPORT_SYMBOL(omap_mcpdm_set_uplink); +EXPORT_SYMBOL(omap_mcpdm_set_downlink); +EXPORT_SYMBOL(omap_mcpdm_clr_uplink); +EXPORT_SYMBOL(omap_mcpdm_clr_downlink); +EXPORT_SYMBOL(omap_mcpdm_request); +EXPORT_SYMBOL(omap_mcpdm_free); way too many exported symbols, no ? Doesn't ALSA API have proper place for this kind of stuff ? I'd need ALSA experts to reply to that but it does smell funny... With the McBSP these things are all exported because the McBSP isn't just used by ALSA, I beleive, but a PDM interface is probably only ever going to be used by audio. thanks for the explanation :-) -- 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 3/4 v4] musb: Add context save and restore support
On Tue, Dec 15, 2009 at 02:31:48PM +0100, ext Ajay Kumar Gupta wrote: Adding support for MUSB register save and restore during system suspend and resume. Changes: - Added musb_save/restore_context() functions - Added platform specific musb_platform_save/restore_context() to handle platform specific jobs. - Maintaining BlackFin compatibility by adding read/write functions for registers which are not available in BlackFin Tested system suspend and resume on OMAP3EVM board. Signed-off-by: Anand Gadiyar gadi...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com applied, thanks -- 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: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, December 15, 2009 12:38 PM To: Cousson, Benoit Cc: Sripathy, Vishwanath; Nayak, Rajendra; ext-ari.kau...@nokia.com; linux- o...@vger.kernel.org; Woodruff, Richard; Menon, Nishanth Subject: RE: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype Hi Benoît, Vishwanath, Thanks for the info, Benoît. On Fri, 11 Dec 2009, Cousson, Benoit wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Thursday, December 10, 2009 10:24 PM Hi Vishwanath, On Tue, 1 Dec 2009, Sripathy, Vishwanath wrote: Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, November 30, 2009 3:00 PM To: Sripathy, Vishwanath Cc: ext-ari.kau...@nokia.com; linux-omap@vger.kernel.org; Woodruff, Richard; Menon, Nishanth Subject: Re: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype Hello Vishwanath, a few comments: On Thu, 26 Nov 2009, Vishwanath BS wrote: From: Richard Woodruff r-woodru...@ti.com DPLL4 for 3630 introduces a changed block requiring special divisor bits and additional reg fields. To allow for silicons to use this, this is introduced as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon Tested with 3630 ZOOM3 Could you please consider Ari Kauppi's suggestions that he posted on 30 and 31 October? They look good to me. Here is a link: Regarding comments from Ari Kauppi on addition of dco_sel_mask and sd_div_mask, yes I had a look at them. However I feel, it's better to have these masks in the structure variable. Reason being this approach will help us to support when dpll types for other dplls get changed in future. For example, if dpll3 block is changed, then having new mask will help us to support it. Is there a product coming out that will add more j-type DPLLs with different dco_sel_masks and sd_div_masks? If not, then let's go with Ari's suggested changes, since we don't really know if any more of these j-type DPLLs will be used. We can always add the fields back in when we need them. But if you know for sure that there is a chip variant coming out soon that will use more j-type DPLLs, let's talk about it. OMAP4 is using the same J-type for the DPLL_USB. The programming model is almost the same... sd_div is a the same location, but dco_sel is not there anymore because that DPLL will always be locked at 960MHz and thus will not require the mode for frequency 1GHz. At the DCO location, we have the bypass_clksel, so the code will have to take care of that. 31:24 DPLL_SD_DIV 23DPLL_BYP_CLKSEL 19:8 DPLL_MULT 7:0 DPLL_DIV Vishwanath, it sounds like it makes sense to hardcode the DPLL_SD_DIV and DCO_SEL shifts, since, so far, when present, they are always at the same offset. Instead of using a 'u8 jtype;' it seems to make sense to have a 'u8 flags' and have at least two flags there: DPLL_J_TYPE and DPLL_NO_DCO_SEL. (The latter flag would skip any DCO_SEL reads/writes for J-type DPLLs if it is set, so it will be usable for OMAP4. The code should also warn if DPLL_NO_DCO_SEL is set and DPLL_J_TYPE is not set.) Sound reasonable? Make sense. I will post new set of patches after incorporating all these. Thanks. - 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
No device for DAI omap-eac-dai error
Hi, I'm writing new omap dai (for EAC codec base omap's). My code is based on existing omap-mcbsp.c code basically. After loadingof module I got error which appear in init function when call snd_soc_register_dai(). I browse for code but can't figure out where dai-dev should be set to don't get error message and init dai properly. Thanks for any suggestions Marek -- To unsubscribe from this list: send the line unsubscribe 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: Flush the D-cache during copy_user_highpage breaks compile for v7 on -rc1
Hi, On Fri, Dec 18, 2009 at 08:18:52AM +, Russell King - ARM Linux wrote: On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: Hi Catalin, You may have already run into this, but if not, looks like commit 115b22474eb1905da2f606a057da345583d3 breaks compile for v7: arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing': arch/arm/mm/copypage-v6.c:51: error: implicit declaration of function '__cpuc_flush_dcache_page' Undoing that makes it work again. It's a combination of changes - my initial changes for fixing the ARMv7 DMA support went in last night, but were based on a tree older than Catalin's changes, which had already been committed. My test build didn't catch any of these - it's the usual problem that there is no way to adequately build-test the ARM kernel in a reasonable time anymore. FWIW: I've added an omap3_defconfig, that should be a superset of the configs used on the OMAP3 boards, to catch as much as possible affecting those boards with one single build. Takes about 90 seconds for me to build on a $600 PC, and Stephen builds it for every linux-next too. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Flush the D-cache during copy_user_highpage breaks compile for v7 on -rc1
On Fri, Dec 18, 2009 at 09:35:12AM -0600, Olof Johansson wrote: Hi, On Fri, Dec 18, 2009 at 08:18:52AM +, Russell King - ARM Linux wrote: On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: Hi Catalin, You may have already run into this, but if not, looks like commit 115b22474eb1905da2f606a057da345583d3 breaks compile for v7: arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing': arch/arm/mm/copypage-v6.c:51: error: implicit declaration of function '__cpuc_flush_dcache_page' Undoing that makes it work again. It's a combination of changes - my initial changes for fixing the ARMv7 DMA support went in last night, but were based on a tree older than Catalin's changes, which had already been committed. My test build didn't catch any of these - it's the usual problem that there is no way to adequately build-test the ARM kernel in a reasonable time anymore. FWIW: I've added an omap3_defconfig, that should be a superset of the configs used on the OMAP3 boards, to catch as much as possible affecting those boards with one single build. Takes about 90 seconds for me to build on a $600 PC, and Stephen builds it for every linux-next too. linux-next is fine if you're prepared to wait a minimum of 36-48 hours between committing and seeing the results - that's unfortunately how it works out if you're in the UK due to time zone differences. The big problem is not so much how long a single build takes, but all builds to get the required converage. We have soo many combinations and configurations that its now impossible to properly build-test changes. It's become soo bad that for most of the changes I do, I hardly ever bother doing in-depth build tests anymore. And that applies inspite of having a nice new Lenovo T500. That's something I've repeatedly warned about, and been faced but why do we want to support a single kernel running on multiple platforms arguments... My method of working now is based around doing my own build tests, merging them into mainline and checking (next morning) the results from kautobuild. I really don't bother checking linux-next, because 36-48 hours is just far too long - by the time the results become available I've moved already on. Plus, lets not forget that kautobuild runs through every single ARM configuration. linux-next only does a subset. -- To unsubscribe from this list: send the line unsubscribe 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: remove duplicated #include
Remove duplicated #include('s) in
drivers/video/omap/lcd_omap3beagle.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
drivers/video/omap/lcd_omap3beagle.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap/lcd_omap3beagle.c
b/drivers/video/omap/lcd_omap3beagle.c
index ca75cc2..ac715f9 100644
--- a/drivers/video/omap/lcd_omap3beagle.c
+++ b/drivers/video/omap/lcd_omap3beagle.c
@@ -26,7 +26,6 @@
#include linux/i2c/twl.h
#include plat/mux.h
-#include plat/mux.h
#include asm/mach-types.h
#include omapfb.h
--
1.6.1.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 2/3] ASoC: OMAP4: Add support for McPDM
Felipe Balbi wrote: Hi, On Fri, Dec 18, 2009 at 03:23:14AM +0100, ext Candelaria Villareal, Jorge wrote: Is this because if two interrupts were set, my approach would not recognize it as one of the cases and exit without processing the interrupt? you don't have a break in your switch. your approach would go through all irq cases no matter what :-p Mmm... But it _does_ have some breaks. Besides, I am still unsure that if structure should be used here. Code would be duplicated, for example, DN_IRQ_FULL and DN_IRQ_EMPTY share the same procedure to acknowledge the request.-- To unsubscribe from this list: send the line unsubscribe 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 01/12] OMAP OPP: remove some unnecessary variables
Paul Walmsley p...@pwsan.com writes: No need to allocate new variables; the passed-in OPP list pointers do nicely as iterators. Thanks Paul for this series. I totally agree with the cleanups you've done. I've rebased this on top of my current pm-wip-opp branch and will include it in the next push of that branch for broader use and testing. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] dsp-bridge: PM cleanups
From: Felipe Contreras felipe.contre...@nokia.com These patches apply on top of a commit in Omar's wip dspbridge-baseline: cd0c004e5c6bc9da58d03931766115ec1e8bcaaf They are supposed to replace Compilation fixes 2.6.31. Felipe Contreras (2): dsp-bridge: improve PM conditional code dsp-bridge: remove unused includes arch/arm/mach-omap2/dspbridge.c |2 ++ drivers/dsp/bridge/rmgr/drv_interface.c |8 drivers/dsp/bridge/rmgr/proc.c |1 - drivers/dsp/bridge/wmd/tiomap3430_pwr.c |3 +-- 4 files changed, 7 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] dsp-bridge: improve PM conditional code
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- arch/arm/mach-omap2/dspbridge.c |2 ++ drivers/dsp/bridge/rmgr/drv_interface.c |5 - drivers/dsp/bridge/wmd/tiomap3430_pwr.c |2 +- 3 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c index 9724a95..ea109a3 100644 --- a/arch/arm/mach-omap2/dspbridge.c +++ b/arch/arm/mach-omap2/dspbridge.c @@ -13,7 +13,9 @@ #include linux/platform_device.h +#ifdef CONFIG_BRIDGE_DVFS #include mach/omap-pm.h +#endif #include dspbridge/host_os.h diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/drivers/dsp/bridge/rmgr/drv_interface.c index 6415955..90d4bad 100644 --- a/drivers/dsp/bridge/rmgr/drv_interface.c +++ b/drivers/dsp/bridge/rmgr/drv_interface.c @@ -96,8 +96,10 @@ #include dspbridge/drv.h #endif +#ifdef CONFIG_BRIDGE_DVFS #include mach/omap-pm.h #include mach-omap2/omap3-opp.h +#endif #define BRIDGE_NAME C6410 /* --- Globals */ @@ -147,7 +149,6 @@ static int omap34xxbridge_suspend_lockout( } return 0; } - #endif #ifdef DEBUG @@ -459,8 +460,10 @@ static int __devexit omap34xx_bridge_remove(struct platform_device *pdev) DBC_Assert(ret == true); } +#ifdef CONFIG_BRIDGE_DVFS clk_put(clk_handle); clk_handle = NULL; +#endif /* #ifdef CONFIG_BRIDGE_DVFS */ func_cont: MEM_ExtPhysPoolRelease(); diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c index ea299a0..8a0cb02 100644 --- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c +++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c @@ -68,8 +68,8 @@ #ifdef CONFIG_PM #include mach/board-3430sdp.h -#endif extern s32 dsp_test_sleepstate; +#endif extern struct MAILBOX_CONTEXT mboxsetting; /* -- 1.6.6.rc2.5.g49666 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] dsp-bridge: remove unused includes
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/dsp/bridge/rmgr/drv_interface.c |3 --- drivers/dsp/bridge/rmgr/proc.c |1 - drivers/dsp/bridge/wmd/tiomap3430_pwr.c |1 - 3 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/drivers/dsp/bridge/rmgr/drv_interface.c index 90d4bad..8c804af 100644 --- a/drivers/dsp/bridge/rmgr/drv_interface.c +++ b/drivers/dsp/bridge/rmgr/drv_interface.c @@ -59,8 +59,6 @@ #include linux/moduleparam.h #include linux/cdev.h -#include mach/board-3430sdp.h - /* --- DSP/BIOS Bridge */ #include dspbridge/std.h #include dspbridge/dbdefs.h @@ -97,7 +95,6 @@ #endif #ifdef CONFIG_BRIDGE_DVFS -#include mach/omap-pm.h #include mach-omap2/omap3-opp.h #endif diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index 1ab6181..267f29c 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -142,7 +142,6 @@ /* --- This */ #include dspbridge/proc.h #include dspbridge/pwr.h -#include mach-omap2/omap3-opp.h #ifndef RES_CLEANUP_DISABLE #include dspbridge/resourcecleanup.h diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c index 8a0cb02..fd6097d 100644 --- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c +++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c @@ -67,7 +67,6 @@ #include mach-omap2/cm-regbits-34xx.h #ifdef CONFIG_PM -#include mach/board-3430sdp.h extern s32 dsp_test_sleepstate; #endif extern struct MAILBOX_CONTEXT mboxsetting; -- 1.6.6.rc2.5.g49666 -- To unsubscribe from this list: send the line unsubscribe 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/4] OPP layer: hide OPP implementation details
This series continues on top of Paul's OPP cleanup series and aims to completly hide the OPP layer implementation details. To do this, a couple more temporary (a.k.a already deprecated) helper functions have been added so current SR/SRF code can still function. The goal here is to allow continued OPP layer cleanup and possibly alternate implementations to be done in parallel with the ongoing SR/SRF rework efforts. Unless I hear some objections, this series will be added onto my pm-wip-opp branch after some more thorough testing. Kevin Hilman (4): OMAP OPP: Add accessor function for getting OPP ID. OMAP OPP: add helper function to find OPP by index OMAP SR/SRF: use OPP API for OPP ID, find by index OMAP OPP: hide struct omap_opp internals in OPP layer implementation arch/arm/mach-omap2/resource34xx.c| 14 -- arch/arm/mach-omap2/smartreflex.c |4 +- arch/arm/plat-omap/include/plat/opp.h | 23 - arch/arm/plat-omap/opp.c | 43 + 4 files changed, 61 insertions(+), 23 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] OMAP OPP: add helper function to find OPP by index
Current SRF code indexes directly into OPP array, add
opp_find_by_index() to do equivalent so OPP layer details can be
further hidden.
NOTE: This is temporary patch until SRF removal can be completed.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/opp.h |3 +++
arch/arm/plat-omap/opp.c | 19 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 6fe574c..038a5c0 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -245,6 +245,9 @@ struct omap_opp * __deprecated opp_find_by_opp_id(struct
omap_opp *opps,
u8 opp_id);
u8 __deprecated opp_get_opp_id(struct omap_opp *opp);
+struct omap_opp *__deprecated opp_find_by_index(struct omap_opp *opps,
+ u8 index);
+
void opp_init_cpufreq_table(struct omap_opp *opps,
struct cpufreq_frequency_table **table);
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 106ad92..71b021b 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -90,6 +90,25 @@ int opp_get_opp_count(struct omap_opp *oppl)
return n;
}
+/**
+ * opp_find_by_opp_index - look up OPP by OPP ID (deprecated)
+ * @opps: pointer to an array of struct omap_opp
+ *
+ * Returns the struct omap_opp pointer corresponding to the given
+ * array index.
+ */
+struct omap_opp *__deprecated opp_find_by_index(struct omap_opp *opps,
+ u8 index)
+{
+ if (!opps)
+ return NULL;
+
+ if (index = opp_get_opp_count(opps))
+ return NULL;
+
+ return opps[index];
+}
+
struct omap_opp *opp_find_freq_exact(struct omap_opp *oppl,
unsigned long freq, bool enabled)
{
--
1.6.6.rc2.1.g42108
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] DSPBRIDGE: return right error codes services directory
From c69aeb206fe38e2ca8a5d3f019672963f262b180 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Thu, 17 Dec 2009 11:53:30 -0600
Subject: [PATCH] DSPBRIDGE: return right error codes services directory
This patch fixes the bad error codes returned by some functions,
also it is taking cafe about some status returned by
functions which were not checked before and removing unused check
or status variables.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/services/cfg.c |8 +---
drivers/dsp/bridge/services/clk.c |7 ++-
drivers/dsp/bridge/services/reg.c | 26 +++---
drivers/dsp/bridge/services/sync.c |1 -
4 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/dsp/bridge/services/cfg.c
b/drivers/dsp/bridge/services/cfg.c
index b45a94c..1275ad3 100644
--- a/drivers/dsp/bridge/services/cfg.c
+++ b/drivers/dsp/bridge/services/cfg.c
@@ -194,8 +194,7 @@ DSP_STATUS CFG_GetExecFile(struct CFG_DEVNODE *hDevNode,
u32 ulBufSize,
ulBufSize, pstrExecFile);
if (!hDevNode)
status = CFG_E_INVALIDHDEVNODE;
-
- if (!pstrExecFile)
+ else if (!pstrExecFile)
status = CFG_E_INVALIDPOINTER;
if (DSP_SUCCEEDED(status)) {
@@ -277,9 +276,13 @@ DSP_STATUS CFG_GetObject(OUT u32 *pdwValue, u32 dwType)
switch (dwType) {
case (REG_DRV_OBJECT):
status = REG_GetValue(DRVOBJECT, (u8 *)pdwValue, dwBufSize);
+ if (DSP_FAILED(status))
+ status = CFG_E_RESOURCENOTAVAIL;
break;
case (REG_MGR_OBJECT):
status = REG_GetValue(MGROBJECT, (u8 *)pdwValue, dwBufSize);
+ if (DSP_FAILED(status))
+ status = CFG_E_RESOURCENOTAVAIL;
break;
default:
break;
@@ -289,7 +292,6 @@ DSP_STATUS CFG_GetObject(OUT u32 *pdwValue, u32 dwType)
CFG_GetObject SUCCESS DrvObject:
0x%x\n , *pdwValue);
} else {
- status = CFG_E_RESOURCENOTAVAIL;
*pdwValue = 0;
GT_0trace(CFG_debugMask, GT_6CLASS, CFG_GetObject Failed \n);
}
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index a56f01e..9a18e11 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -173,9 +173,7 @@ DSP_STATUS CLK_Enable(IN enum SERVICES_ClkId clk_id)
pClk = SERVICES_Clks[clk_id].clk_handle;
if (pClk) {
- if (clk_enable(pClk) == 0x0) {
- /* Success ? */
- } else {
+ if (clk_enable(pClk)) {
pr_err(CLK_Enable: failed to Enable CLK %s,
CLK dev id = %s\n,
SERVICES_Clks[clk_id].clk_name,
@@ -209,8 +207,7 @@ DSP_STATUS CLK_Set_32KHz(IN enum SERVICES_ClkId clk_id)
DSP_STATUS status = DSP_SOK;
struct clk *pClk;
struct clk *pClkParent;
- enum SERVICES_ClkId sys_32k_id = SERVICESCLK_sys_32k_ck;
- pClkParent = SERVICES_Clks[sys_32k_id].clk_handle;
+ pClkParent = SERVICES_Clks[SERVICESCLK_sys_32k_ck].clk_handle;
DBC_Require(clk_id SERVICESCLK_NOT_DEFINED);
GT_2trace(CLK_debugMask, GT_6CLASS, CLK_Set_32KHz: CLK %s,
diff --git a/drivers/dsp/bridge/services/reg.c
b/drivers/dsp/bridge/services/reg.c
index 03b99fd..9f7cfcf 100644
--- a/drivers/dsp/bridge/services/reg.c
+++ b/drivers/dsp/bridge/services/reg.c
@@ -52,17 +52,14 @@ static unsigned int crefs; /* module counter */
DSP_STATUS REG_DeleteValue(IN CONST char *pstrValue)
{
DSP_STATUS status;
- DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
+ DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
GT_0trace(REG_debugMask, GT_ENTER, REG_DeleteValue: entered\n);
SYNC_EnterCS(reglock);
- if (regsupDeleteValue(pstrValue) == DSP_SOK)
- status = DSP_SOK;
- else
- status = DSP_EFAIL;
-
+ status = regsupDeleteValue(pstrValue);
SYNC_LeaveCS(reglock);
+
return status;
}
@@ -169,18 +166,17 @@ DSP_STATUS REG_SetValue(IN CONST char *pstrValue, IN u8
*pbData,
DBC_Require(pstrValue pbData);
DBC_Require(dwDataSize 0);
- DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
+ DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
SYNC_EnterCS(reglock);
- /* We need to use regsup calls... */
- /* ...for now we don't need the key handle or */
- /* the subkey, all we need is the value to lookup. */
- if (regsupSetValue((char *)pstrValue, pbData, dwDataSize) == DSP_SOK)
- status = DSP_SOK;
- else
- status = DSP_EFAIL;
-
+ /*
+* We need to use regsup calls
+
[PATCH 2/2] DSPBRIDGE: remove unused things in clk.c and mem.c
From 70a2d5a2c8e59679f90e7e4fce084a7ea02ce0da Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Thu, 17 Dec 2009 11:57:11 -0600
Subject: [PATCH] DSPBRIDGE: remove unused things in clk.c and mem.c
This patch removes unused define from mem.c and unused
struct in clk.c.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/services/clk.c |5 -
drivers/dsp/bridge/services/mem.c |1 -
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index 9a18e11..e7b282d 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -82,11 +82,6 @@ static struct SERVICES_Clk_t SERVICES_Clks[] = {
{NULL, }
};
-/* Generic TIMER object: */
-struct TIMER_OBJECT {
- struct timer_list timer;
-};
-
/* --- Globals */
#if GT_TRACE
static struct GT_Mask CLK_debugMask = { NULL, NULL }; /* GT trace variable */
diff --git a/drivers/dsp/bridge/services/mem.c
b/drivers/dsp/bridge/services/mem.c
index f0dd9fc..d937c7c 100644
--- a/drivers/dsp/bridge/services/mem.c
+++ b/drivers/dsp/bridge/services/mem.c
@@ -33,7 +33,6 @@
#include dspbridge/list.h
/* --- Defines */
-#define MEM_512MB 0x1fff
#define memInfoSign 0x464E494D /* MINF (in reverse). */
#ifdef CONFIG_BRIDGE_DEBUG
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4 clock code needs some modifying now that clockdomains are present
Hi Abhijit, going through the clock code, I noticed that it still has several #ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */ Could you please put together a patch to remove these, test it on 4430ES1 SDP, and send it to the list? I'd suggest basing the patches on my upstream queue for .34, which is available at: git://git.pwsan.com/linux-2.6 for_2_6_34 thanks, - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] DSPBRIDGE: return right error codes services directory
On Fri, Dec 18, 2009 at 8:15 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: From c69aeb206fe38e2ca8a5d3f019672963f262b180 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Thu, 17 Dec 2009 11:53:30 -0600 Subject: [PATCH] DSPBRIDGE: return right error codes services directory This patch fixes the bad error codes returned by some functions, also it is taking cafe about some status returned by Typo: s/cafe/care/ Although I'm not sure the sentence is grammatically correct. /me shrugs. -- 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
[RESEND][PATCH 1/2] DSPBRIDGE: return right error codes services directory
Fixed typo in description.
From c69aeb206fe38e2ca8a5d3f019672963f262b180 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Thu, 17 Dec 2009 11:53:30 -0600
Subject: [PATCH] DSPBRIDGE: return right error codes services directory
This patch fixes the bad error codes returned by some functions,
also checks for status not checked before and removes unused checks
or status variables.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/services/cfg.c |8 +---
drivers/dsp/bridge/services/clk.c |7 ++-
drivers/dsp/bridge/services/reg.c | 26 +++---
drivers/dsp/bridge/services/sync.c |1 -
4 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/dsp/bridge/services/cfg.c
b/drivers/dsp/bridge/services/cfg.c
index b45a94c..1275ad3 100644
--- a/drivers/dsp/bridge/services/cfg.c
+++ b/drivers/dsp/bridge/services/cfg.c
@@ -194,8 +194,7 @@ DSP_STATUS CFG_GetExecFile(struct CFG_DEVNODE *hDevNode,
u32 ulBufSize,
ulBufSize, pstrExecFile);
if (!hDevNode)
status = CFG_E_INVALIDHDEVNODE;
-
- if (!pstrExecFile)
+ else if (!pstrExecFile)
status = CFG_E_INVALIDPOINTER;
if (DSP_SUCCEEDED(status)) {
@@ -277,9 +276,13 @@ DSP_STATUS CFG_GetObject(OUT u32 *pdwValue, u32 dwType)
switch (dwType) {
case (REG_DRV_OBJECT):
status = REG_GetValue(DRVOBJECT, (u8 *)pdwValue, dwBufSize);
+ if (DSP_FAILED(status))
+ status = CFG_E_RESOURCENOTAVAIL;
break;
case (REG_MGR_OBJECT):
status = REG_GetValue(MGROBJECT, (u8 *)pdwValue, dwBufSize);
+ if (DSP_FAILED(status))
+ status = CFG_E_RESOURCENOTAVAIL;
break;
default:
break;
@@ -289,7 +292,6 @@ DSP_STATUS CFG_GetObject(OUT u32 *pdwValue, u32 dwType)
CFG_GetObject SUCCESS DrvObject:
0x%x\n , *pdwValue);
} else {
- status = CFG_E_RESOURCENOTAVAIL;
*pdwValue = 0;
GT_0trace(CFG_debugMask, GT_6CLASS, CFG_GetObject Failed \n);
}
diff --git a/drivers/dsp/bridge/services/clk.c
b/drivers/dsp/bridge/services/clk.c
index a56f01e..9a18e11 100644
--- a/drivers/dsp/bridge/services/clk.c
+++ b/drivers/dsp/bridge/services/clk.c
@@ -173,9 +173,7 @@ DSP_STATUS CLK_Enable(IN enum SERVICES_ClkId clk_id)
pClk = SERVICES_Clks[clk_id].clk_handle;
if (pClk) {
- if (clk_enable(pClk) == 0x0) {
- /* Success ? */
- } else {
+ if (clk_enable(pClk)) {
pr_err(CLK_Enable: failed to Enable CLK %s,
CLK dev id = %s\n,
SERVICES_Clks[clk_id].clk_name,
@@ -209,8 +207,7 @@ DSP_STATUS CLK_Set_32KHz(IN enum SERVICES_ClkId clk_id)
DSP_STATUS status = DSP_SOK;
struct clk *pClk;
struct clk *pClkParent;
- enum SERVICES_ClkId sys_32k_id = SERVICESCLK_sys_32k_ck;
- pClkParent = SERVICES_Clks[sys_32k_id].clk_handle;
+ pClkParent = SERVICES_Clks[SERVICESCLK_sys_32k_ck].clk_handle;
DBC_Require(clk_id SERVICESCLK_NOT_DEFINED);
GT_2trace(CLK_debugMask, GT_6CLASS, CLK_Set_32KHz: CLK %s,
diff --git a/drivers/dsp/bridge/services/reg.c
b/drivers/dsp/bridge/services/reg.c
index 03b99fd..9f7cfcf 100644
--- a/drivers/dsp/bridge/services/reg.c
+++ b/drivers/dsp/bridge/services/reg.c
@@ -52,17 +52,14 @@ static unsigned int crefs; /* module counter */
DSP_STATUS REG_DeleteValue(IN CONST char *pstrValue)
{
DSP_STATUS status;
- DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
+ DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
GT_0trace(REG_debugMask, GT_ENTER, REG_DeleteValue: entered\n);
SYNC_EnterCS(reglock);
- if (regsupDeleteValue(pstrValue) == DSP_SOK)
- status = DSP_SOK;
- else
- status = DSP_EFAIL;
-
+ status = regsupDeleteValue(pstrValue);
SYNC_LeaveCS(reglock);
+
return status;
}
@@ -169,18 +166,17 @@ DSP_STATUS REG_SetValue(IN CONST char *pstrValue, IN u8
*pbData,
DBC_Require(pstrValue pbData);
DBC_Require(dwDataSize 0);
- DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
+ DBC_Require(strlen(pstrValue) REG_MAXREGPATHLENGTH);
SYNC_EnterCS(reglock);
- /* We need to use regsup calls... */
- /* ...for now we don't need the key handle or */
- /* the subkey, all we need is the value to lookup. */
- if (regsupSetValue((char *)pstrValue, pbData, dwDataSize) == DSP_SOK)
- status = DSP_SOK;
- else
- status = DSP_EFAIL;
-
+ /*
+* We need to use regsup calls
+* for now we
Re: [PATCH 10/12] OMAP OPP: remove initial terminators from OPP lists
Paul Walmsley p...@pwsan.com writes:
Now that the SRF and Smartreflex code uses accessor functions to interact
with OPPs, the initial terminators can be removed.
Nice.
With the initial terminators gone, some assumptions in SRF have to be
changed too where SRF is directly indexing into the OPP table.
I'll fix that up in an updated version of my 'hide OPP details' series.
Kevin
---
arch/arm/plat-omap/opp.c | 36
1 files changed, 8 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 596e3ee..f651912 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -53,15 +53,15 @@ unsigned long opp_get_freq(const struct omap_opp *opp)
struct omap_opp * __deprecated opp_find_by_opp_id(struct omap_opp *opps,
u8 opp_id)
{
- int i = 1;
+ int i = 0;
if (!opps || !opp_id)
return NULL;
- /* The first entry is a dummy one, loop till we hit terminator */
while (!OPP_TERM(opps[i])) {
if (opps[i].enabled (opps[i].opp_id == opp_id))
return opps[i];
+
i++;
}
@@ -76,7 +76,6 @@ int opp_get_opp_count(struct omap_opp *oppl)
pr_err(%s: Invalid parameters being passed\n, __func__);
return -EINVAL;
}
- oppl++; /* skip initial terminator */
while (!OPP_TERM(oppl)) {
if (oppl-enabled)
n++;
@@ -92,9 +91,7 @@ struct omap_opp *opp_find_freq_exact(struct omap_opp *oppl,
pr_err(%s: Invalid parameters being passed\n, __func__);
return ERR_PTR(-EINVAL);
}
- /* skip initial terminator */
- if (OPP_TERM(oppl))
- oppl++;
+
while (!OPP_TERM(oppl)) {
if ((oppl-rate == freq) (oppl-enabled == enabled))
break;
@@ -111,10 +108,6 @@ struct omap_opp *opp_find_freq_ceil(struct omap_opp
*oppl, unsigned long *freq)
return ERR_PTR(-EINVAL);
}
- /* skip initial terminator */
- if (OPP_TERM(oppl))
- oppl++;
-
while (!OPP_TERM(oppl)) {
if (oppl-enabled oppl-rate = *freq)
break;
@@ -139,10 +132,6 @@ struct omap_opp *opp_find_freq_floor(struct omap_opp
*oppl, unsigned long *freq)
return ERR_PTR(-EINVAL);
}
- /* skip initial terminator */
- if (OPP_TERM(oppl))
- oppl++;
-
while (!OPP_TERM(oppl)) {
if (oppl-enabled) {
if (oppl-rate *freq)
@@ -181,20 +170,16 @@ struct omap_opp *opp_add(struct omap_opp *oppl,
pr_err(%s: Invalid params being passed\n, __func__);
return ERR_PTR(-EINVAL);
}
- /* need a start terminator.. */
- if (unlikely(!OPP_TERM(oppl))) {
- pr_err(%s: Expected a start terminator!!\n, __func__);
- return ERR_PTR(-EINVAL);
- }
+
n = 0;
opp = oppl;
- opp++;
while (!OPP_TERM(opp)) {
n++;
opp++;
}
+
/* lets now reallocate memory */
- oppr = kmalloc(sizeof(struct omap_opp) * (n + 3), GFP_KERNEL);
+ oppr = kmalloc(sizeof(struct omap_opp) * (n + 2), GFP_KERNEL);
if (!oppr) {
pr_err(%s: No memory for new opp array\n, __func__);
return ERR_PTR(-ENOMEM);
@@ -204,7 +189,7 @@ struct omap_opp *opp_add(struct omap_opp *oppl,
opp = oppl;
oppt = oppr;
ins = 0;
- i = 0;
+ i = 1;
do {
if (ins || opp-rate opp_def-freq) {
memcpy(oppt, opp, sizeof(struct omap_opp));
@@ -249,17 +234,12 @@ struct omap_opp __init *opp_init_list(const struct
omap_opp_def *opp_defs)
t++;
}
- oppl = kmalloc(sizeof(struct omap_opp) * (n + 2), GFP_KERNEL);
+ oppl = kmalloc(sizeof(struct omap_opp) * (n + 1), GFP_KERNEL);
if (!oppl) {
pr_err(%s: No memory for opp array\n, __func__);
return ERR_PTR(-ENOMEM);
}
opp = oppl;
- /* Setup start terminator - SRF depends on this for indexing :( */
- opp-rate = 0;
- opp-enabled = 0;
- opp-u_volt = 0;
- opp++;
while (n) {
omap_opp_populate(opp, opp_defs);
opp-opp_id = i;
--
To unsubscribe from this list: send the line unsubscribe 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: Anyone using an ISP1505?
Gadiyar, Anand wrote: I'm working on an OMAP3530CUS board that uses an ISP1505 USB PHY, and I haven't gotten much luck getting the kernel to recognize any USB devices. No luck, actually. :) My oscilloscope and the schematic say that the hardware is wired up properly, I'm just wondering if anyone has a similar configuration that's working for them--- and which kernel they are using? Is it with the OTG controller or with the EHCI controller? The pins of the ISP1505 are tied to pins T24, T23, and so on of the OMAP3530CUS, which on my schematic are labeled UH0_D0, UH0_D1, etc. That's EHCI, right? But I have both the EHCI and MUSB drivers enabled, and both appear to initialize properly according to the kernel logs. The NXP ISP1505 is supposed to be transparent - no programming usually required. That's what I thought. I have the nop transceiver driver installed. If it's with the EHCI controller, you need to take care of a couple of issues on the board (due to the input clocking mode used in the OMAP3). Can you elaborate? Thanks! b.g. -- Bill Gatliff b...@billgatliff.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: Anyone using an ISP1505?
Felipe Balbi wrote: is this with musb ? if it's musb, you need the nop transceiver. Do you have any boot logs which you could share ? Without information on the board, is a bit difficult :-( Of course. Here is an excerpt from my dmesg output: Linux version 2.6.33-rc1-06888-g7fa9fb6-dirty (b...@mercury) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #22 Fri Dec 18 18:58:00 UTC 2009 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: TBD Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c0467a3c, node_mem_map c0485000 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32512 pages, LIFO batch:7 OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=nfs nfsroot=192.168.2.10:/exports/tbd rw ip=192.168.2.168:192.168.2.10:192.168.2.1:255.255.255.0:tbd:eth0:off console=ttyS1,115200n8 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 125168KB available (3992K code, 310K data, 164K init, 0K highmem) Hierarchical RCU implementation. RCU-based detection of stalled CPUs is enabled. NR_IRQS:388 Clocking rate (Crystal/Core/MPU): 19.2/332/545 MHz Reprogramming SDRC clock to 33200 Hz GPMC revision 5.0 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP GPIO hardware version 2.5 OMAP clockevent source: GPTIMER12 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 524.12 BogoMIPS (lpj=2048000) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 mux: Setting signal mcbsp_clks.mcbsp_clks 0x0100 - 0x0100 mux: Setting signal mcbsp2_fsx.mcbsp2_fsx 0x0018 - 0x0100 mux: Setting signal mcbsp2_clkx.mcbsp2_clkx 0x0018 - 0x0100 mux: Setting signal mcbsp2_dx.mcbsp2_dx 0x0018 - 0x mux: Setting signal mcbsp2_dr.mcbsp2_dr 0x0100 - 0x0100 mux: Setting signal i2c1_scl.i2c1_scl 0x0118 - 0x0118 mux: Setting signal i2c1_sda.i2c1_sda 0x0118 - 0x0118 mux: Setting signal sys_clkout1.sys_clkout1 0x0100 - 0x mux: Setting signal hsusb0_clk.hsusb0_clk 0x0100 - 0x mux: Setting signal hsusb0_stp.hsusb0_stp 0x0018 - 0x mux: Setting signal hsusb0_dir.hsusb0_dir 0x0100 - 0x0100 mux: Setting signal hsusb0_nxt.hsusb0_nxt 0x0100 - 0x0100 mux: Setting signal
[PATCH] omap: zoom3: enable ehci support
Zoom3 board has omap3630 EHCI port2 connected to a ULPI phy.
GPIO_64 is connected to the PHY reset pin.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Cc: Gadiyar, Anand gadi...@ti.com
---
arch/arm/mach-omap2/board-zoom3.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index a9fe918..a5e8036 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -20,6 +20,8 @@
#include plat/common.h
#include plat/board.h
+#include plat/usb.h
+#include plat/mux.h
#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
@@ -51,11 +53,25 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = -EINVAL,
+ .reset_gpio_port[1] = 64,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init omap_zoom_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
zoom_debugboard_init();
+
+ omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
+ usb_ehci_init(ehci_pdata);
}
MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)
--
1.6.6.rc0.66.ge160d
--
To unsubscribe from this list: send the line unsubscribe 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: Flush the D-cache during copy_user_highpage breaks compile for v7 on -rc1
On Fri, 18 Dec 2009, Russell King - ARM Linux wrote: On Thu, Dec 17, 2009 at 07:19:24PM -0800, Tony Lindgren wrote: Hi Catalin, You may have already run into this, but if not, looks like commit 115b22474eb1905da2f606a057da345583d3 breaks compile for v7: arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing': arch/arm/mm/copypage-v6.c:51: error: implicit declaration of function '__cpuc_flush_dcache_page' Undoing that makes it work again. It's a combination of changes - my initial changes for fixing the ARMv7 DMA support went in last night, but were based on a tree older than Catalin's changes, which had already been committed. My test build didn't catch any of these - it's the usual problem that there is no way to adequately build-test the ARM kernel in a reasonable time anymore. This is why we have a community of people reporting such issues, and a long -rc period to fix them. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sergey Nikitin si Vás přidal do přátel na s tránce VK.com
linux omap(at)vger.kernel.org, Sergey Nikitin si Vás přidal do přátel na stránce VK.com Pomocí své e-mailové adresy a automaticky vytvořeného hesla: PJ2uDN34, můžete zajít na stránku a prohlédnout si profily Vašich přátel. VK.com je stránka, která každý den umožňuje desítkám milionů lidí najít staré přátele a zůstavat s nimi ve spojení, sdílet s nimi fotky i nejdůležitější události. Abyste se dostal(a) na stránku, přejděte na odkaz: http://vk.com/login.php?regemail=linux-o...@vger.kernel.org#pj2udn34 Upozornění: Pokud budete toto pozvání ignorovat, Vaše registrace nebude aktivována. Hodně štěstí! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 clock code needs some modifying now that clockdomains are present
Hi Abhijit, On Fri, 18 Dec 2009, Paul Walmsley wrote: going through the clock code, I noticed that it still has several #ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */ Just noticed this also in clock44xx_data.c: /* TODO omap2_init_clk_clkdm(c-lk.clk); */ - 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
[PATCH v2 3/4] OMAP SR/SRF: use OPP API for OPP ID, remove direct access
SR and SRF currenly direclty access OPP struct internals. Use new accessor function to get OPP ID. Also SRF was doing doing direct access of the OPP struct array using a convoluted conversion from a 'level' to an OPP ID, when they're actually the same thing. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/resource34xx.c |6 +++--- arch/arm/mach-omap2/smartreflex.c |4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index 1fa8bb5..31b8af2 100644 --- a/arch/arm/mach-omap2/resource34xx.c +++ b/arch/arm/mach-omap2/resource34xx.c @@ -204,7 +204,7 @@ static int __deprecated freq_to_opp(u8 *opp_id, struct omap_opp *opps, opp = opp_find_freq_ceil(opps, freq); if (IS_ERR(opp)) return -EINVAL; - *opp_id = opp-opp_id; + *opp_id = opp_get_opp_id(opp); return 0; } @@ -337,8 +337,8 @@ static int program_opp(int res, struct omap_opp *opp, int target_level, #ifdef CONFIG_OMAP_SMARTREFLEX unsigned long t_opp, c_opp; - t_opp = ID_VDD(res) | ID_OPP_NO(opp[target_level - 1].opp_id); - c_opp = ID_VDD(res) | ID_OPP_NO(opp[current_level - 1].opp_id); + t_opp = ID_VDD(res) | ID_OPP_NO(target_level - 1); + c_opp = ID_VDD(res) | ID_OPP_NO(current_level - 1); #endif /* See if have a freq associated, if not, invalid opp */ diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 9c0d5bf..d341857 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -159,7 +159,7 @@ static u8 get_vdd1_opp(void) if (IS_ERR(opp)) return 0; - return opp-opp_id; + return opp_get_opp_id(opp); } static u8 get_vdd2_opp(void) @@ -174,7 +174,7 @@ static u8 get_vdd2_opp(void) if (IS_ERR(opp)) return 0; - return opp-opp_id; + return opp_get_opp_id(opp); } -- 1.6.6.rc2.1.g42108 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] OMAP OPP: hide struct omap_opp internals in OPP layer implementation
Now that we have accessor/helper functions for all the OPP layer
details, move 'struct omap_opp' into the OPP layer so no direct
accesses to OPP internals can be done.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/opp.h | 19 +--
arch/arm/plat-omap/opp.c | 19 +++
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
index 6fe574c..9f91ad3 100644
--- a/arch/arm/plat-omap/include/plat/opp.h
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -17,24 +17,7 @@ extern struct omap_opp *mpu_opps;
extern struct omap_opp *dsp_opps;
extern struct omap_opp *l3_opps;
-/**
- * struct omap_opp - OMAP OPP description structure
- * @enabled: true/false - marking this OPP as enabled/disabled
- * @rate: Frequency in hertz
- * @opp_id:(DEPRECATED) opp identifier
- * @u_volt: minimum microvolts DC required for this OPP to function
- *
- * This structure stores the OPP information for a given domain.
- * Due to legacy reasons, this structure is currently exposed and
- * will soon be removed elsewhere and will only be used as a handle
- * from the OPP internal referencing mechanism
- */
-struct omap_opp {
- bool enabled;
- unsigned long rate;
- unsigned long u_volt;
- u8 __deprecated opp_id;
-};
+struct omap_opp;
/**
* opp_get_voltage() - Gets the voltage corresponding to an opp
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index 4f7fa22..4fe1933 100644
--- a/arch/arm/plat-omap/opp.c
+++ b/arch/arm/plat-omap/opp.c
@@ -19,6 +19,25 @@
#include plat/opp_twl_tps.h
#include plat/opp.h
+/**
+ * struct omap_opp - OMAP OPP description structure
+ * @enabled: true/false - marking this OPP as enabled/disabled
+ * @rate: Frequency in hertz
+ * @opp_id:(DEPRECATED) opp identifier
+ * @u_volt: minimum microvolts DC required for this OPP to function
+ *
+ * This structure stores the OPP information for a given domain.
+ * Due to legacy reasons, this structure is currently exposed and
+ * will soon be removed elsewhere and will only be used as a handle
+ * from the OPP internal referencing mechanism
+ */
+struct omap_opp {
+ bool enabled;
+ unsigned long rate;
+ unsigned long u_volt;
+ u8 opp_id;
+};
+
/*
* DEPRECATED: Meant to detect end of opp array
* This is meant to help co-exist with current SRF etc
--
1.6.6.rc2.1.g42108
--
To unsubscribe from this list: send the line unsubscribe 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/5] arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work
The comments in arm_machine_restart() suggest that cpu_proc_fin()
will clean and disable cache and turn off interrupts. This does
not seem to be implemented for proc-v7.S, implement it the same
way as for proc-v6.S.
This also makes kexec work for v7. Note that a related TLB and
branch traget flush patch is also needed to avoid kexec
crc error.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mm/proc-v7.S |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a28521..d2a8074 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -45,7 +45,14 @@ ENTRY(cpu_v7_proc_init)
ENDPROC(cpu_v7_proc_init)
ENTRY(cpu_v7_proc_fin)
- mov pc, lr
+ stmfd sp!, {lr}
+ cpsid if @ disable interrupts
+ bl v7_flush_kern_cache_all
+ mrc p15, 0, r0, c1, c0, 0 @ ctrl register
+ bic r0, r0, #0x1000 @ ...i
+ bic r0, r0, #0x0006 @ .ca.
+ mcr p15, 0, r0, c1, c0, 0 @ disable caches
+ ldmfd sp!, {pc}
ENDPROC(cpu_v7_proc_fin)
/*
--
To unsubscribe from this list: send the line unsubscribe 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/5] arm: Flush TLB entries in setup_mm_for_reboot()
We need to do that if we tinker with the MMU entries. This fixes the occasional bug with kexec where the new fails to uncompress with crc error. Most likely at least kexec on v6 and v7 need this fix. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mm/mmu.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 8c7fbd1..a2802ea 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -1068,4 +1068,7 @@ void setup_mm_for_reboot(char mode) pmd[1] = __pmd(pmdval + (1 (PGDIR_SHIFT - 1))); flush_pmd_entry(pmd); } + + local_flush_tlb_all(); + flush_cache_all(); } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] arm: Fix init_atags_procfs() to check tag-hdr.size
The tag-hdr.size cannot be larger than XXX.
Otherwise we can getsomething similar during boot:
Unable to handle kernel paging request at virtual address 61a05020
...
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/include/asm/setup.h | 12 +---
arch/arm/kernel/atags.c|2 +-
arch/arm/kernel/compat.c |2 +-
arch/arm/kernel/setup.c|4 ++--
arch/arm/mach-orion5x/common.c |2 +-
5 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 5ccce0a..3ca36bb 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -21,6 +21,11 @@
/* The list ends with an ATAG_NONE node. */
#define ATAG_NONE 0x
+/* Some sanity checks are needed */
+#define ATAG_MAX_SZPAGE_SIZE
+#define atag_valid(tag)
\
+ ((tag)-hdr.size ((tag)-hdr.size = ATAG_MAX_SZ))
+
struct tag_header {
__u32 size;
__u32 tag;
@@ -173,9 +178,10 @@ struct tagtable {
int (*parse)(const struct tag *);
};
-#define tag_member_present(tag,member) \
- ((unsigned long)(((struct tag *)0L)-member + 1) \
- = (tag)-hdr.size * 4)
+#define tag_member_present(tag,member) \
+ (atag_valid(tag) \
+ (((unsigned long)(((struct tag *)0L)-member + 1) \
+ = (tag)-hdr.size * 4))
#define tag_next(t)((struct tag *)((__u32 *)(t) + (t)-hdr.size))
#define tag_size(type) ((sizeof(struct tag_header) + sizeof(struct type)) 2)
diff --git a/arch/arm/kernel/atags.c b/arch/arm/kernel/atags.c
index 42a1a14..14d0993 100644
--- a/arch/arm/kernel/atags.c
+++ b/arch/arm/kernel/atags.c
@@ -51,7 +51,7 @@ static int __init init_atags_procfs(void)
return -EINVAL;
}
- for (; tag-hdr.size; tag = tag_next(tag))
+ for (; atag_valid(tag); tag = tag_next(tag))
;
/* include the terminating ATAG_NONE */
diff --git a/arch/arm/kernel/compat.c b/arch/arm/kernel/compat.c
index 0a13854..3e63ee1 100644
--- a/arch/arm/kernel/compat.c
+++ b/arch/arm/kernel/compat.c
@@ -220,7 +220,7 @@ void __init convert_to_tag_list(struct tag *tags)
void __init squash_mem_tags(struct tag *tag)
{
- for (; tag-hdr.size; tag = tag_next(tag))
+ for (; atag_valid(tag); tag = tag_next(tag))
if (tag-hdr.tag == ATAG_MEM)
tag-hdr.tag = ATAG_NONE;
}
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index c6c57b6..53d7181 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -556,7 +556,7 @@ request_standard_resources(struct meminfo *mi, struct
machine_desc *mdesc)
*/
static int __init parse_tag_core(const struct tag *tag)
{
- if (tag-hdr.size 2) {
+ if ((atag_valid(tag) (tag-hdr.size 2))) {
if ((tag-u.core.flags 1) == 0)
root_mountflags = ~MS_RDONLY;
ROOT_DEV = old_decode_dev(tag-u.core.rootdev);
@@ -660,7 +660,7 @@ static int __init parse_tag(const struct tag *tag)
*/
static void __init parse_tags(const struct tag *t)
{
- for (; t-hdr.size; t = tag_next(t))
+ for (; atag_valid(t); t = tag_next(t))
if (!parse_tag(t))
printk(KERN_WARNING
Ignoring unrecognised tag 0x%08x\n,
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index f87fa12..8afee34 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -717,7 +717,7 @@ void __init orion5x_init(void)
void __init tag_fixup_mem32(struct machine_desc *mdesc, struct tag *t,
char **from, struct meminfo *meminfo)
{
- for (; t-hdr.size; t = tag_next(t))
+ for (; atag_valid(t); t = tag_next(t))
if (t-hdr.tag == ATAG_MEM
(!t-u.mem.size || t-u.mem.size ~PAGE_MASK ||
t-u.mem.start ~PAGE_MASK)) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
