[PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
The use of the spin lock, which supposed to protect the the dma_op_mode causing "INFO: inconsistent lock state" on playback start. Remove the spin locks around the dma_op_mode, when it's purpuse is to protect the dma_op_mode. Signed-off-by: Peter Ujfalusi --- arch/arm/plat-omap/mcbsp.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 88ac976..9b33671 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -298,9 +298,7 @@ int omap_mcbsp_get_dma_op_mode(unsigned int id) } mcbsp = id_to_mcbsp_ptr(id); - spin_lock_irq(&mcbsp->lock); dma_op_mode = mcbsp->dma_op_mode; - spin_unlock_irq(&mcbsp->lock); return dma_op_mode; } @@ -318,7 +316,6 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); - spin_lock_irq(&mcbsp->lock); if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) { syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); @@ -327,7 +324,6 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) } else { syscon |= SIDLEMODE(0x01); } - spin_unlock_irq(&mcbsp->lock); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon); } @@ -1145,9 +1141,7 @@ static ssize_t dma_op_mode_show(struct device *dev, ssize_t len = 0; const char * const *s; - spin_lock_irq(&mcbsp->lock); dma_op_mode = mcbsp->dma_op_mode; - spin_unlock_irq(&mcbsp->lock); for (s = &dma_op_modes[i]; i < ARRAY_SIZE(dma_op_modes); s++, i++) { if (dma_op_mode == i) -- 1.6.5.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
Re: [alsa-devel] [PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tue, 2009-10-27 at 12:00 +0100, Ujfalusi Peter (Nokia-D/Tampere) wrote: > The use of the spin lock, which supposed to protect the the > dma_op_mode causing "INFO: inconsistent lock state" on > playback start. > Remove the spin locks around the dma_op_mode, when it's > purpuse is to protect the dma_op_mode. > > Signed-off-by: Peter Ujfalusi > --- You may wish to double read the message above, as it's quite confusing =) Otherwise, that spinlocking is highly unnecessary and things are far better without than with it. The only case it could be useful is in SMPs, but OMAPs are not such quite yet - and when they are, things will need to be re-though anyway. - Eero -- 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] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tuesday 27 October 2009 13:07:23 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote: > On Tue, 2009-10-27 at 12:00 +0100, Ujfalusi Peter (Nokia-D/Tampere) > > wrote: > > The use of the spin lock, which supposed to protect the the > > dma_op_mode causing "INFO: inconsistent lock state" on > > playback start. > > Remove the spin locks around the dma_op_mode, when it's > > purpuse is to protect the dma_op_mode. > > > > Signed-off-by: Peter Ujfalusi > > --- > > You may wish to double read the message above, as it's quite > confusing =) Yes it is ;) I have left one spinlock around the dma_op_mode, when it also protects the mcbsp->active, so that is why that last sentence. -- Péter -- 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/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
Hi Nishanth, After some testing I have found a little problem with the init > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > > Refactor the smart reflex implementation. [snip] > + return ret; > +} > +late_initcall(omap_sr_init); It seem that with late_initcall we are initializing SR after SGX init. This SGX init call DVFS to change opp and we are not yet initialized this cause the device to hang (Panic Joined) One solution will be to change from late_initcall to device_initcall so SR will be initialized before SGX + return ret; +} +device_initcall(omap_sr_init); Is there any objections or constraint with this ? Or maybe there is another way to fix this ? BR Guilhem -[Panic]-- [8.128723] Unable to handle kernel NULL pointer dereference at virtual address [8.137329] pgd = c0004000 [8.140289] [] *pgd= [8.144042] Internal error: Oops: 5 [#1] PREEMPT [8.148895] Modules linked in: [8.152099] CPU: 0Not tainted (2.6.29-omap1 #43) [8.157409] PC is at sr_vp_disable_both+0x18/0x80 [8.162322] LR is at program_opp+0x80/0x1d0 [8.166717] pc : []lr : []psr: 6013 [8.166717] sp : cec1fce0 ip : cec1fcf8 fp : cec1fcf4 [8.178741] r10: c050d3d8 r9 : 0003 r8 : [8.184204] r7 : r6 : 0010 r5 : 0002 r4 : cec1e000 [8.191040] r3 : r2 : 0042 r1 : 0043 r0 : 0002 [8.197875] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [8.205535] Control: 10c5387d Table: 80c04019 DAC: 0017 [8.211578] [8.211578] PC: 0xc004e1bc: [8.216033] e1bc eb0df5ab ea11 ebfffe8f e2504000 15d51000 11a02004 159f003c 1a06 [8.224639] e1dc e1a5 eb8f e2504000 0a07 e5d51000 e1a02004 e59f0020 eb0df59c [8.233245] e1fc e59f001c e30014bd e3a02000 eb0083d7 e1a4 e89da830 c04632b6 c04632e7 [8.241851] e21c c046330b c046316a e1a0c00d e92dd830 e24cb004 e59f3064 e7e102d0 e5933000 [8.250457] e23c e5d32000 e152 2a02 e3a03000 e5833000 eafd e7935100 e5d53021 [8.259033] e25c e353 0a0a e5d53020 e353 1a07 e1a5 ebc4 e2504000 [8.267639] e27c 0a04 e5d51000 e59f0014 eb0df578 ea00 e3a04000 e1a4 e89da830 [8.276245] e29c c050d3a0 c046332f e1a0c00d e92dddf0 e24cb004 e2535000 e1a06000 e1a07001 [8.284851] [8.284851] LR: 0xc004f4c4: [8.289306] f4c4 e1a0c00d e92ddff0 e24cb004 e24dd024 e50b0040 e1a06182 e0810183 e0811006 [8.297912] f4e4 e50b103c e1a05002 e50b0038 e1a09003 e5d01004 e1a0c00d e51b003c e3cc4d7f [8.306518] f504 e51b2040 e3a08000 e59fa168 e201101f e2023003 e5d02004 e3c4403f e1a07008 [8.315124] f524 e1a03283 e202201f e1832002 e1831001 e1a2 e50b2034 e50b1030 ebfffb37 [8.323730] f544 e1550009 d3a02000 c3a02001 e50b2044 e51b3044 e1570003 1a36 e51bc040 [8.332336] f564 e35c0001 1a0c e59f010c e5903000 e59a0210 e7931006 eb000a65 e59f20fc [8.340942] f584 e59a0214 e5923000 e7931006 eb000a60 ebffdd91 e59f30e8 ea23 e3a01040 [8.349517] f5a4 e3a00c02 ebffdf20 e10f8000 f10c0080 e5943004 e2833001 e5843004 e50b004c [8.358123] [8.358123] SP: 0xcec1fc60: [8.362609] fc60 02c7 cedc0720 cec1fc94 cec1fc80 cec1fccc [8.371215] fc80 0010 cec1fcf4 cec1fc98 c003c9ac c003c200 0002 0043 [8.379821] fca0 0042 cec1e000 0002 0010 0003 [8.388397] fcc0 c050d3d8 cec1fcf4 cec1fcf8 cec1fce0 c004f544 c004e23c 6013 [8.397003] fce0 cec1e000 0002 cec1fd44 cec1fcf8 c004f544 c004e230 [8.405609] fd00 0002 c04db200 c04db208 0042 0043 c04da0a8 [8.414215] fd20 0002 0002 0001 0003 cec1fd7c cec1fd48 [8.422821] fd40 c004f7d4 c004f4d0 c04da0cc 6013 cec1fda4 cec1fd60 c03ccc74 [8.431427] [8.431427] IP: 0xcec1fc78: [8.435882] fc78 cec1fccc 0010 cec1fcf4 cec1fc98 c003c9ac c003c200 [8.88] fc98 0002 0043 0042 cec1e000 0002 0010 [8.453094] fcb8 0003 c050d3d8 cec1fcf4 cec1fcf8 cec1fce0 c004f544 c004e23c [8.461700] fcd8 6013 cec1e000 0002 cec1fd44 cec1fcf8 c004f544 c004e230 [8.470275] fcf8 0002 c04db200 c04db208 0042 0043 [8.478881] fd18 c04da0a8 0002 0002 0001 0003 [8.487487] fd38 cec1fd7c cec1fd48 c004f7d4 c004f4d0 c04da0cc 6013 cec1fda4 cec1fd60 [8.496093] fd58 c03ccc74 c04da0a8 0002 0001 cec1fd94 cec1fd80 [8.504699] [8.504699] FP: 0xcec1fc74: [8.509155] fc74 cec1fc80 cec1fccc 0010 cec1fcf4 cec1fc98 c003c9ac [8.517761] fc94 c003c200 0002 004
Re: [alsa-devel] [PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tue, Oct 27, 2009 at 01:17:52PM +0200, Peter Ujfalusi wrote: > On Tuesday 27 October 2009 13:07:23 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote: > > You may wish to double read the message above, as it's quite > > confusing =) > Yes it is ;) > I have left one spinlock around the dma_op_mode, when it also protects the > mcbsp->active, so that is why that last sentence. I have to confess that I'm still not entirely clear what the lock is supposed to be doing or why it's OK to drop it. I gather that it's just that dmap_on_mode() doesn't need a lock at 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] PM: Fixes warning on suspend errors
Hi, I get the following errors when I choose devices in /sys/power/pm_test. It also shows that if 'dpm_suspend_start' fails somewhere down the line then the kernel does not reset the 'transition_started' variable and we can get warning similar to below. IMHO 'dpm_resume_noirq' is not the right place for setting this variable. Please see the patch below which fixes the issue. Thanks, -Romit # [ 113.713958] mmcblk0: mmc1:0001 STM16G 14.8 GiB [ 113.718902] mmcblk0: unknown partition table [ 113.745574] [ cut here ] [ 113.751525] WARNING: at drivers/base/power/main.c:98 device_pm_add+0x94/0xdc() [ 113.758819] Device: bdi [ 113.758819] Parentless device registered during a PM transaction [ 113.773071] Modules linked in: [ 113.776214] [] (unwind_backtrace+0x0/0xdc) from [] (warn_slowpath_common+0x48/0x60) [ 113.785705] [] (warn_slowpath_common+0x48/0x60) from [] (warn_slowpath_fmt+0x24/0x30) [ 113.799896] [] (warn_slowpath_fmt+0x24/0x30) from [] (device_pm_add+0x94/0xdc) [ 113.808990] [] (device_pm_add+0x94/0xdc) from [] (device_add+0x3a8/0x534) [ 113.817565] [] (device_add+0x3a8/0x534) from [] (device_create_vargs+0x78/0xa8) [ 113.829650] [] (device_create_vargs+0x78/0xa8) from [] (bdi_register+0x3c/0x154) [ 113.839263] [] (bdi_register+0x3c/0x154) from [] (bdi_register_dev+0x20/0x28) [ 113.851348] [] (bdi_register_dev+0x20/0x28) from [] (add_disk+0xe4/0x124) [ 113.859954] [] (add_disk+0xe4/0x124) from [] (mmc_blk_probe+0x250/0x288) [ 113.870513] [] (mmc_blk_probe+0x250/0x288) from [] (mmc_bus_probe+0x18/0x1c) [ 113.879394] [] (mmc_bus_probe+0x18/0x1c) from [] (driver_probe_device+0xa0/0x14c) [ 113.893890] [] (driver_probe_device+0xa0/0x14c) from [] (bus_for_each_drv+0x44/0x80) [ 113.905609] [] (bus_for_each_drv+0x44/0x80) from [] (device_attach+0x50/0x68) [ 113.914550] [] (device_attach+0x50/0x68) from [] (bus_probe_device+0x24/0x40) [ 113.925170] [] (bus_probe_device+0x24/0x40) from [] (device_add+0x3dc/0x534) [ 113.934082] [] (device_add+0x3dc/0x534) from [] (mmc_add_card+0xcc/0x118) [ 113.945251] [] (mmc_add_card+0xcc/0x118) from [] (mmc_attach_mmc+0xdc/0x13c) [ 113.954132] [] (mmc_attach_mmc+0xdc/0x13c) from [] (mmc_rescan+0x2b0/0x2e8) [ 113.964874] [] (mmc_rescan+0x2b0/0x2e8) from [] (worker_thread+0x16c/0x218) [ 113.973693] [] (worker_thread+0x16c/0x218) from [] (kthread+0x7c/0x84) [ 113.986694] [] (kthread+0x7c/0x84) from [] (kernel_thread_exit+0x0/0x8) [ 113.995147] ---[ end trace aaa7bf5becc572f5 ]--- Fixes the location where we decide that our power transition is complete. Signed-off-by: Romit Dasgupta --- diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index e0dc407..6b9e991 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -365,7 +365,6 @@ void dpm_resume_noirq(pm_message_t state) struct device *dev; mutex_lock(&dpm_list_mtx); - transition_started = false; list_for_each_entry(dev, &dpm_list, power.entry) if (dev->power.status > DPM_OFF) { int error; @@ -529,6 +528,7 @@ static void dpm_complete(pm_message_t state) put_device(dev); } list_splice(&list, &dpm_list); + transition_started = false; mutex_unlock(&dpm_list_mtx); } -- 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] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tuesday 27 October 2009 14:00:09 ext Mark Brown wrote: > > I have to confess that I'm still not entirely clear what the lock is > supposed to be doing or why it's OK to drop it. I gather that it's just > that dmap_on_mode() doesn't need a lock at all? In my opinion it does not need a lock. If the user space is so broken that it is doing different things in parallel, I would rather crash the kernel if it is possible to force someone to fix the mess upstairs. But the lock is not needed, I think it was a result of over-engineering. -- Péter -- 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] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tue, 2009-10-27 at 13:00 +0100, ext Mark Brown wrote: > On Tue, Oct 27, 2009 at 01:17:52PM +0200, Peter Ujfalusi wrote: > > On Tuesday 27 October 2009 13:07:23 Nurkkala Eero.An (EXT-Offcode/Oulu) > > wrote: > > > > You may wish to double read the message above, as it's quite > > > confusing =) > > > Yes it is ;) > > I have left one spinlock around the dma_op_mode, when it also protects the > > mcbsp->active, so that is why that last sentence. > > I have to confess that I'm still not entirely clear what the lock is > supposed to be doing or why it's OK to drop it. I gather that it's just > that dmap_on_mode() doesn't need a lock at all? Mostly thinko's with this locking: - spin_lock_irq(&mcbsp->lock); dma_op_mode = mcbsp->dma_op_mode; - spin_unlock_irq(&mcbsp->lock); return dma_op_mode; --> same as return mcbsp->dma_op_mode; and worst, it's called from pcm_trigger() -> so irqs are enabled -> lockdep isn't happy -> so currently things are pretty much "broken". - Eero -- 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/4] RX51: SDRAM settings changes
>-Original Message- >From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] >Sent: 26 October, 2009 20:50 >To: Kristo Tero (Nokia-D/Tampere) >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 0/4] RX51: SDRAM settings changes > >Tero Kristo writes: > >> From: Tero Kristo >> >> Following patch set fixes a few issues with current RX51 >board SDRAM settings. >> Applies on top of PM branch. >> > >Tero, > >Can you resend this series against the master branch? There >is no reason >this should be carried in the PM branch anymore. > >You'll have to add to your series the patch to add the >board-rx51-sdram.c file, which I currently carry in the PM branch. > >Then, for the PM branch, we just need a small patch to add the various >rate tables in the call to init_common_hw until DVFS stuff is >upstream. Ok, I have now done this. I also combined the series into one patch as it will generate a new file and I don't see any need to clutter git-log with several patches to currently non-existent file. Sending out now. -Tero -- 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] RX51: Add SDRAM init
From: Tero Kristo This patch adds board specific SDRAM init for RX51. This patch is a collaboration of work from following people: Juha Yrjola: Original code Lauri Leukkunen: Port to RX51 Tero Kristo: Support for multiple OPP:s, merge of patches Samu Onkalo: Fixed SDRAM parameters according to specs Kalle Jokiniemi: A fix for rounding error Signed-off-by: Tero Kristo Cc: Samu Onkalo Cc: Kalle Jokiniemi Cc: Lauri Leukkunen Cc: Juha Yrjola --- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-rx51-sdram.c | 221 arch/arm/mach-omap2/board-rx51.c |7 +- 3 files changed, 228 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-rx51-sdram.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 03cb4fc..9cd745a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -69,6 +69,7 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ mmc-twl4030.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ + board-rx51-sdram.o \ board-rx51-peripherals.o \ mmc-twl4030.o obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \ diff --git a/arch/arm/mach-omap2/board-rx51-sdram.c b/arch/arm/mach-omap2/board-rx51-sdram.c new file mode 100644 index 000..f392844 --- /dev/null +++ b/arch/arm/mach-omap2/board-rx51-sdram.c @@ -0,0 +1,221 @@ +/* + * SDRC register values for RX51 + * + * Copyright (C) 2008 Nokia Corporation + * + * Lauri Leukkunen + * + * Original code by Juha Yrjola + * + * 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 +#include +#include +#include + +#include +#include +#include +#include + + +/* In picoseconds, except for tREF (ns), tXP, tCKE, tWTR (clks) */ +struct sdram_timings { + u32 casl; + u32 tDAL; + u32 tDPL; + u32 tRRD; + u32 tRCD; + u32 tRP; + u32 tRAS; + u32 tRC; + u32 tRFC; + u32 tXSR; + + u32 tREF; /* in ns */ + + u32 tXP; + u32 tCKE; + u32 tWTR; +}; + +struct omap_sdrc_params rx51_sdrc_params[4]; + +static const struct sdram_timings rx51_timings[] = { + { + .casl = 3, + .tDAL = 33000, + .tDPL = 15000, + .tRRD = 12000, + .tRCD = 22500, + .tRP = 18000, + .tRAS = 42000, + .tRC = 66000, + .tRFC = 138000, + .tXSR = 20, + + .tREF = 7800, + + .tXP = 2, + .tCKE = 2, + .tWTR = 2 + }, +}; + +static unsigned long sdrc_get_fclk_period(long rate) +{ + /* In picoseconds */ + return 10 / rate; +} + +static unsigned int sdrc_ps_to_ticks(unsigned int time_ps, long rate) +{ + unsigned long tick_ps; + + /* Calculate in picosecs to yield more exact results */ + tick_ps = sdrc_get_fclk_period(rate); + + return (time_ps + tick_ps - 1) / tick_ps; +} +#undef DEBUG +#ifdef DEBUG +static int set_sdrc_timing_regval(u32 *regval, int st_bit, int end_bit, + int ticks, long rate, const char *name) +#else +static int set_sdrc_timing_regval(u32 *regval, int st_bit, int end_bit, + int ticks) +#endif +{ + int mask, nr_bits; + + nr_bits = end_bit - st_bit + 1; + if (ticks >= 1 << nr_bits) + return -1; + mask = (1 << nr_bits) - 1; + *regval &= ~(mask << st_bit); + *regval |= ticks << st_bit; +#ifdef DEBUG + printk(KERN_INFO "SDRC %s: %i ticks %i ns\n", name, ticks, + (unsigned int)sdrc_get_fclk_period(rate) * ticks / + 1000); +#endif + + return 0; +} + +#ifdef DEBUG +#define SDRC_SET_ONE(reg, st, end, field, rate) \ + if (set_sdrc_timing_regval((reg), (st), (end), \ + rx51_timings->field, (rate), #field) < 0) \ + err = -1; +#else +#define SDRC_SET_ONE(reg, st, end, field, rate) \ + if (set_sdrc_timing_regval((reg), (st), (end), \ + rx51_timings->field) < 0) \ + err = -1; +#endif + +#ifdef DEBUG +static int set_sdrc_timing_regval_ps(u32 *regval, int st_bit, int end_bit, + int time, long rate, const char *name) +#else +static int set_sdrc_timing_regval_ps(u32 *regval, int st_bit, int end_bit, + int time, long rate) +#endif +{ + int ticks, ret; + ret = 0; + + if (time == 0) + ticks = 0; + else +
Re: [linux-pm] [PATCH] PM: Fixes warning on suspend errors
On Tue, 27 Oct 2009, Dasgupta, Romit wrote: > Hi, > I get the following errors when I choose devices in /sys/power/pm_test. > It also shows that if 'dpm_suspend_start' fails somewhere down the line then > the kernel does not reset the 'transition_started' variable and we can get > warning similar to below. IMHO 'dpm_resume_noirq' is not the right place for > setting this variable. Please see the patch below which fixes the issue. > Fixes the location where we decide that our power transition is complete. > Signed-off-by: Romit Dasgupta > --- > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > index e0dc407..6b9e991 100644 > --- a/drivers/base/power/main.c > +++ b/drivers/base/power/main.c > @@ -365,7 +365,6 @@ void dpm_resume_noirq(pm_message_t state) > struct device *dev; > > mutex_lock(&dpm_list_mtx); > - transition_started = false; > list_for_each_entry(dev, &dpm_list, power.entry) > if (dev->power.status > DPM_OFF) { > int error; > @@ -529,6 +528,7 @@ static void dpm_complete(pm_message_t state) > put_device(dev); > } > list_splice(&list, &dpm_list); > + transition_started = false; > mutex_unlock(&dpm_list_mtx); > } The second hunk is okay, but the first hunk isn't. We want to set transition_started to false as soon as devices start resuming, because once a resume has begun it's okay to add new devices. Alan Stern -- 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] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tue, 27 Oct 2009 13:07:23 +0200 Eero Nurkkala wrote: > Otherwise, that spinlocking is highly unnecessary and things are > far better without than with it. The only case it could be useful > is in SMPs, but OMAPs are not such quite yet - and when they > are, things will need to be re-though anyway. > Following commit is suggesting that mcbsp code *must* be SMP safe already now: commit a5b92cc348299c20be215b9f4b50853ecfbf3864 Author: Syed Rafiuddin Date: Tue Jul 28 18:57:10 2009 +0530 ARM: OMAP4: Add McBSP support -- Jarkko -- 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] Introduce support for AM35xx
This patch adds support for the recently announced AM3505 and AM3517 devices from Texas Instruments. It also defines the AM3517 EVM board. Detailed support will follow in subsequent patches. [1] http://www.ti.com/sitara [2] http://www.ti.com/arm [3] http://tiexpressdsp.com/index.php?title=Applications_Processors_Crossreference [4] http://marc.info/?l=linux-omap&m=125615009412281&w=2 The patches have been created against omap-next branch. Sanjeev Premi (2): AM35xx: Runtime detection of the device AM35xx: Define the AM3517EVM board arch/arm/mach-omap2/Kconfig |4 +++ arch/arm/mach-omap2/id.c | 43 arch/arm/plat-omap/include/plat/cpu.h | 12 + 3 files changed, 53 insertions(+), 6 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] AM35xx: Runtime detection of the device
Add support to detect AM3505/AM3517 devices at runtime. Also updates the CPU names printed during boot. Signed-off-by: Sanjeev Premi --- arch/arm/mach-omap2/id.c | 43 arch/arm/plat-omap/include/plat/cpu.h | 12 + 2 files changed, 49 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 1c15112..87efb73 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -242,6 +242,21 @@ void __init omap3_check_revision(void) omap_revision = OMAP3630_REV_ES1_0; } break; + case 0xb868: + /* Handle OMAP35xx/AM35xx devices +* +* Set the device to be OMAP3517 here. Actual device +* is identified later based on the features. +*/ + switch (rev) { + case 0: + omap_revision = OMAP3505_REV(rev); + break; + default: + /* Use the latest known revision as default */ + omap_revision = OMAP3505_REV(rev); + } + break; default: /* Unknown default to latest silicon rev as default*/ omap_revision = OMAP3630_REV_ES1_0; @@ -267,20 +282,36 @@ void __init omap3_cpuinfo(void) * and CPU class bits. */ if (cpu_is_omap3630()) - strcpy(cpu_name, "3630"); + strcpy(cpu_name, "OMAP3630"); + else if (omap_rev() && OMAP35XX_CLASS) { + /* +* AM3517, AM3505 devices +*/ + if (omap3_has_sgx()) { + omap_revision = OMAP3517_REV(rev); + strcpy(cpu_name, "AM3517"); + } + else { + /* Already set in omap3_check_revision() */ + strcpy(cpu_name, "AM3505"); + } + } + /* +* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices +*/ else if (omap3_has_iva() && omap3_has_sgx()) - strcpy(cpu_name, "3430/3530"); + strcpy(cpu_name, "OMAP3430/3530"); else if (omap3_has_sgx()) { omap_revision = OMAP3525_REV(rev); - strcpy(cpu_name, "3525"); + strcpy(cpu_name, "OMAP3525"); } else if (omap3_has_iva()) { omap_revision = OMAP3515_REV(rev); - strcpy(cpu_name, "3515"); + strcpy(cpu_name, "OMAP3515"); } else { omap_revision = OMAP3503_REV(rev); - strcpy(cpu_name, "3503"); + strcpy(cpu_name, "OMAP3503"); } switch (rev) { @@ -307,7 +338,7 @@ void __init omap3_cpuinfo(void) /* * Print verbose information */ - pr_info("OMAP%s ES%s\n", cpu_name, cpu_rev); + pr_info("%s ES%s\n", cpu_name, cpu_rev); OMAP3_SHOW_FEATURE(l2cache); OMAP3_SHOW_FEATURE(iva); diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 7cb0556..f1cc913 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -284,6 +284,8 @@ IS_OMAP_SUBCLASS(363x, 0x363) * cpu_is_omap2423(): True for OMAP2423 * cpu_is_omap2430(): True for OMAP2430 * cpu_is_omap3430(): True for OMAP3430 + * cpu_is_omap3505(): True for OMAP3505 + * cpu_is_omap3517(): True for OMAP3517 */ #define GET_OMAP_TYPE ((omap_rev() >> 16) & 0x) @@ -307,6 +309,8 @@ IS_OMAP_TYPE(2422, 0x2422) IS_OMAP_TYPE(2423, 0x2423) IS_OMAP_TYPE(2430, 0x2430) IS_OMAP_TYPE(3430, 0x3430) +IS_OMAP_TYPE(3505, 0x3505) +IS_OMAP_TYPE(3517, 0x3517) #define cpu_is_omap310() 0 #define cpu_is_omap730() 0 @@ -325,6 +329,8 @@ IS_OMAP_TYPE(3430, 0x3430) #define cpu_is_omap3515() 0 #define cpu_is_omap3525() 0 #define cpu_is_omap3530() 0 +#define cpu_is_omap3505() 0 +#define cpu_is_omap3517() 0 #define cpu_is_omap3430() 0 #define cpu_is_omap3630() 0 @@ -380,6 +386,8 @@ IS_OMAP_TYPE(3430, 0x3430) # undef cpu_is_omap3515 # undef cpu_is_omap3525 # undef cpu_is_omap3530 +# undef cpu_is_omap3505 +# undef cpu_is_omap3517 # define cpu_is_omap3430() is_omap3430() # define cpu_is_omap3503 (cpu_is_omap3430() && \ (!omap3_has_iva()) && \ @@ -391,6 +399,8 @@ IS_OMAP_TYPE(3430, 0x3430) (omap3_has_sgx()) &&\ (!omap3_has_iva())) # define cpu_is_omap3530 (cpu_is_omap3430()) +# define cpu_is_omap3505 is_omap3505() +# define cpu_is_omap3517 is_omap3
[PATCH 2/2] AM35xx: Define the AM3517EVM board
Add support for the AM3517 EVM board. This EVM supports AM3505 and AM3517 devices. Signed-off-by: Sanjeev Premi --- arch/arm/mach-omap2/Kconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 8685df5..c904580 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -65,6 +65,10 @@ config MACH_OMAP3EVM bool "OMAP 3530 EVM board" depends on ARCH_OMAP3 && ARCH_OMAP34XX +config MACH_OMAP3517EVM + bool "OMAP3517/ AM3517 EVM board" + depends on ARCH_OMAP3 && ARCH_OMAP34XX + config MACH_OMAP3_PANDORA bool "OMAP3 Pandora" depends on ARCH_OMAP3 && ARCH_OMAP34XX -- 1.6.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-pm] [PATCH] PM: Fixes warning on suspend errors
Ok. Then the following is the refined and probably more appropriate one. This fixes the point where we need to complete the power transition when device suspend fails. Signed-off-by: Romit Dasgupta --- diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index e0dc407..3d0b26a 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -444,6 +444,7 @@ static void dpm_resume(pm_message_t state) INIT_LIST_HEAD(&list); mutex_lock(&dpm_list_mtx); + transition_started = false; while (!list_empty(&dpm_list)) { struct device *dev = to_device(dpm_list.next); > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Alan Stern > Sent: Tuesday, October 27, 2009 7:08 PM > To: Dasgupta, Romit > Cc: Hilman, Kevin; r...@sisk.pl; linux...@lists.linux-foundation.org; linux- > o...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [linux-pm] [PATCH] PM: Fixes warning on suspend errors > > On Tue, 27 Oct 2009, Dasgupta, Romit wrote: > > > Hi, > > I get the following errors when I choose devices in > > /sys/power/pm_test. It > also shows that if 'dpm_suspend_start' fails somewhere down the line then > the kernel does not reset the 'transition_started' variable and we can get > warning similar to below. IMHO 'dpm_resume_noirq' is not the right place for > setting this variable. Please see the patch below which fixes the issue. > > > Fixes the location where we decide that our power transition is complete. > > Signed-off-by: Romit Dasgupta > > --- > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c > > index e0dc407..6b9e991 100644 > > --- a/drivers/base/power/main.c > > +++ b/drivers/base/power/main.c > > @@ -365,7 +365,6 @@ void dpm_resume_noirq(pm_message_t state) > > struct device *dev; > > > > mutex_lock(&dpm_list_mtx); > > - transition_started = false; > > list_for_each_entry(dev, &dpm_list, power.entry) > > if (dev->power.status > DPM_OFF) { > > int error; > > @@ -529,6 +528,7 @@ static void dpm_complete(pm_message_t state) > > put_device(dev); > > } > > list_splice(&list, &dpm_list); > > + transition_started = false; > > mutex_unlock(&dpm_list_mtx); > > } > > The second hunk is okay, but the first hunk isn't. We want to set > transition_started to false as soon as devices start resuming, because > once a resume has begun it's okay to add new devices. > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] AM35xx: Runtime detection of the device
Hi, On Tue, Oct 27, 2009 at 03:02:30PM +0100, ext Sanjeev Premi wrote: > Add support to detect AM3505/AM3517 devices at runtime. > Also updates the CPU names printed during boot. > > Signed-off-by: Sanjeev Premi > --- > arch/arm/mach-omap2/id.c | 43 > arch/arm/plat-omap/include/plat/cpu.h | 12 + > 2 files changed, 49 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > index 1c15112..87efb73 100644 > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -242,6 +242,21 @@ void __init omap3_check_revision(void) > omap_revision = OMAP3630_REV_ES1_0; > } > break; > + case 0xb868: > + /* Handle OMAP35xx/AM35xx devices > + * > + * Set the device to be OMAP3517 here. Actual device > + * is identified later based on the features. > + */ > + switch (rev) { > + case 0: > + omap_revision = OMAP3505_REV(rev); > + break; > + default: > + /* Use the latest known revision as default */ > + omap_revision = OMAP3505_REV(rev); if both are the same, what's the point of having this switch ? > + } > + break; > default: > /* Unknown default to latest silicon rev as default*/ > omap_revision = OMAP3630_REV_ES1_0; > @@ -267,20 +282,36 @@ void __init omap3_cpuinfo(void) >* and CPU class bits. >*/ > if (cpu_is_omap3630()) > - strcpy(cpu_name, "3630"); > + strcpy(cpu_name, "OMAP3630"); > + else if (omap_rev() && OMAP35XX_CLASS) { > + /* > + * AM3517, AM3505 devices > + */ > + if (omap3_has_sgx()) { > + omap_revision = OMAP3517_REV(rev); > + strcpy(cpu_name, "AM3517"); > + } > + else { according to CodingStyle this should be: } else { -- 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] AM35xx: Runtime detection of the device
> -Original Message- > From: Premi, Sanjeev > Sent: Tuesday, October 27, 2009 7:33 PM > To: linux-omap@vger.kernel.org > Cc: Premi, Sanjeev > Subject: [PATCH 1/2] AM35xx: Runtime detection of the device > > Add support to detect AM3505/AM3517 devices at runtime. > Also updates the CPU names printed during boot. > > Signed-off-by: Sanjeev Premi > --- > arch/arm/mach-omap2/id.c | 43 > > arch/arm/plat-omap/include/plat/cpu.h | 12 + > 2 files changed, 49 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > index 1c15112..87efb73 100644 > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -242,6 +242,21 @@ void __init omap3_check_revision(void) > omap_revision = OMAP3630_REV_ES1_0; > } > break; > + case 0xb868: > + /* Handle OMAP35xx/AM35xx devices > + * > + * Set the device to be OMAP3517 here. Actual device > + * is identified later based on the features. > + */ > + switch (rev) { > + case 0: > + omap_revision = OMAP3505_REV(rev); > + break; > + default: > + /* Use the latest known revision as default */ > + omap_revision = OMAP3505_REV(rev); > + } > + break; > default: > /* Unknown default to latest silicon rev as default*/ > omap_revision = OMAP3630_REV_ES1_0; > @@ -267,20 +282,36 @@ void __init omap3_cpuinfo(void) >* and CPU class bits. >*/ > if (cpu_is_omap3630()) > - strcpy(cpu_name, "3630"); > + strcpy(cpu_name, "OMAP3630"); > + else if (omap_rev() && OMAP35XX_CLASS) { [sp] Just noticed that this should have been a "&" instead of "&&"; a copy paste while re-working. ... better still, cpu_is_omap3505(). ~sanjeev > + /* > + * AM3517, AM3505 devices > + */ > + if (omap3_has_sgx()) { > + omap_revision = OMAP3517_REV(rev); > + strcpy(cpu_name, "AM3517"); > + } > + else { > + /* Already set in omap3_check_revision() */ > + strcpy(cpu_name, "AM3505"); > + } > + } > + /* > + * OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices > + */ > else if (omap3_has_iva() && omap3_has_sgx()) > - strcpy(cpu_name, "3430/3530"); > + strcpy(cpu_name, "OMAP3430/3530"); > else if (omap3_has_sgx()) { > omap_revision = OMAP3525_REV(rev); > - strcpy(cpu_name, "3525"); > + strcpy(cpu_name, "OMAP3525"); > } > else if (omap3_has_iva()) { > omap_revision = OMAP3515_REV(rev); > - strcpy(cpu_name, "3515"); > + strcpy(cpu_name, "OMAP3515"); > } > else { > omap_revision = OMAP3503_REV(rev); > - strcpy(cpu_name, "3503"); > + strcpy(cpu_name, "OMAP3503"); > } > > switch (rev) { > @@ -307,7 +338,7 @@ void __init omap3_cpuinfo(void) > /* >* Print verbose information >*/ > - pr_info("OMAP%s ES%s\n", cpu_name, cpu_rev); > + pr_info("%s ES%s\n", cpu_name, cpu_rev); > > OMAP3_SHOW_FEATURE(l2cache); > OMAP3_SHOW_FEATURE(iva); > diff --git a/arch/arm/plat-omap/include/plat/cpu.h > b/arch/arm/plat-omap/include/plat/cpu.h > index 7cb0556..f1cc913 100644 > --- a/arch/arm/plat-omap/include/plat/cpu.h > +++ b/arch/arm/plat-omap/include/plat/cpu.h > @@ -284,6 +284,8 @@ IS_OMAP_SUBCLASS(363x, 0x363) > * cpu_is_omap2423():True for OMAP2423 > * cpu_is_omap2430():True for OMAP2430 > * cpu_is_omap3430():True for OMAP3430 > + * cpu_is_omap3505():True for OMAP3505 > + * cpu_is_omap3517():True for OMAP3517 > */ > #define GET_OMAP_TYPE((omap_rev() >> 16) & 0x) > > @@ -307,6 +309,8 @@ IS_OMAP_TYPE(2422, 0x2422) > IS_OMAP_TYPE(2423, 0x2423) > IS_OMAP_TYPE(2430, 0x2430) > IS_OMAP_TYPE(3430, 0x3430) > +IS_OMAP_TYPE(3505, 0x3505) > +IS_OMAP_TYPE(3517, 0x3517) > > #define cpu_is_omap310() 0 > #define cpu_is_omap730() 0 > @@ -325,6 +329,8 @@ IS_OMAP_TYPE(3430, 0x3430) > #define cpu_is_omap3515()0 > #define cpu_is_omap3525()0 > #define cpu_is_omap3530()0 > +#define cpu_is_omap3505()0 > +#define cpu_is_omap3517()0 > #define cpu_is_omap3430()0 > #define cpu_is_omap3630()0 > > @@ -380,6 +386,8 @@ IS_OMAP_TYPE(3430, 0x3430) > # undef cpu_is_omap3515 > # undef cpu_is_omap3525 > # undef cpu_is_omap3530 > +# undef cpu_is_omap3505 > +# undef cpu_is_omap3517 > # define cpu_is_omap3430() is_omap
RE: [PATCH 1/2] AM35xx: Runtime detection of the device
> -Original Message- > From: Felipe Balbi [mailto:felipe.ba...@nokia.com] > Sent: Tuesday, October 27, 2009 9:41 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 1/2] AM35xx: Runtime detection of the device > > Hi, > > On Tue, Oct 27, 2009 at 03:02:30PM +0100, ext Sanjeev Premi wrote: > > Add support to detect AM3505/AM3517 devices at runtime. > > Also updates the CPU names printed during boot. > > > > Signed-off-by: Sanjeev Premi > > --- > > arch/arm/mach-omap2/id.c | 43 > > > arch/arm/plat-omap/include/plat/cpu.h | 12 + > > 2 files changed, 49 insertions(+), 6 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > > index 1c15112..87efb73 100644 > > --- a/arch/arm/mach-omap2/id.c > > +++ b/arch/arm/mach-omap2/id.c > > @@ -242,6 +242,21 @@ void __init omap3_check_revision(void) > > omap_revision = OMAP3630_REV_ES1_0; > > } > > break; > > + case 0xb868: > > + /* Handle OMAP35xx/AM35xx devices > > +* > > +* Set the device to be OMAP3517 here. Actual device > > +* is identified later based on the features. > > +*/ > > + switch (rev) { > > + case 0: > > + omap_revision = OMAP3505_REV(rev); > > + break; > > + default: > > + /* Use the latest known revision as default */ > > + omap_revision = OMAP3505_REV(rev); > > if both are the same, what's the point of having this switch ? [sp] I was just following the style for 3630, while re-basing this patch :( > > > + } > > + break; > > default: > > /* Unknown default to latest silicon rev as default*/ > > omap_revision = OMAP3630_REV_ES1_0; > > @@ -267,20 +282,36 @@ void __init omap3_cpuinfo(void) > > * and CPU class bits. > > */ > > if (cpu_is_omap3630()) > > - strcpy(cpu_name, "3630"); > > + strcpy(cpu_name, "OMAP3630"); > > + else if (omap_rev() && OMAP35XX_CLASS) { > > + /* > > +* AM3517, AM3505 devices > > +*/ > > + if (omap3_has_sgx()) { > > + omap_revision = OMAP3517_REV(rev); > > + strcpy(cpu_name, "AM3517"); > > + } > > + else { > > according to CodingStyle this should be: > > } else { [sp] Yes. Missed it. > > -- > 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: [ANNOUNCE] updated dspbridge on linux-omap
On Tue, 20 Oct 2009, Ramirez Luna, Omar wrote: > Also, DVFS Bridge feature won't compile if rebasing onto PM branch > because it is missing clk notifier functions. This should not break compilation. The DSPBridge code must use platform_data function pointers to call clock notifier functions. Also, on a related note, I see that EXPORT_SYMBOL() entries have been added for many OPP-related functions in plat-omap/omap-pm-*.c. This is not the right way to do it. These also should be called via platform_data function pointers. Then your code will compile no matter whether the OMAP clock notifier or OMAP PM patches are present or not. The point here is to keep the device drivers completely separate from architecture-level code, so you could, for example, use DSPBridge on a DaVinci platform. I will post a patch to remove the EXPORT_SYMBOL() entries from the OMAP PM code. - 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] OMAP PM: Remove symbol exports
This patch applies against the PM branch. Commit b32960d2fd88085d6270c4f3a2f708e7ce42cd7b exported many of the functions from the OMAP PM layer, presumably to allow device drivers to call them directly. This ties the device drivers to the OMAP platform; they will not compile or work on other platforms, e.g., DaVinci. Device driver code should be platform-independent. This patch removes the EXPORT_SYMBOL() lines. Rather than relying on exported symbols, device drivers should instead pass pointers to these functions via function pointers in struct platform_device.platform_data. Then the device driver code should use an idiom similar to: if (pdata->function_name) pdata->function_name(arg1, arg2, ...); Signed-off-by: Paul Walmsley Cc: Ameya Palande Cc: Kevin Hilman --- arch/arm/plat-omap/omap-pm-noop.c |7 --- arch/arm/plat-omap/omap-pm-srf.c |7 --- 2 files changed, 0 insertions(+), 14 deletions(-) diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-pm-noop.c index d3c7279..cab105f 100644 --- a/arch/arm/plat-omap/omap-pm-noop.c +++ b/arch/arm/plat-omap/omap-pm-noop.c @@ -157,7 +157,6 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void) return NULL; } -EXPORT_SYMBOL(omap_pm_dsp_get_opp_table); void omap_pm_dsp_set_min_opp(u8 opp_id) { @@ -182,7 +181,6 @@ void omap_pm_dsp_set_min_opp(u8 opp_id) * */ } -EXPORT_SYMBOL(omap_pm_dsp_set_min_opp); u8 omap_pm_dsp_get_opp(void) { @@ -198,7 +196,6 @@ u8 omap_pm_dsp_get_opp(void) return 0; } -EXPORT_SYMBOL(omap_pm_dsp_get_opp); u8 omap_pm_vdd1_get_opp(void) { @@ -210,7 +207,6 @@ u8 omap_pm_vdd1_get_opp(void) return 0; } -EXPORT_SYMBOL(omap_pm_vdd1_get_opp); u8 omap_pm_vdd2_get_opp(void) { @@ -222,7 +218,6 @@ u8 omap_pm_vdd2_get_opp(void) return 0; } -EXPORT_SYMBOL(omap_pm_vdd2_get_opp); /* * CPUFreq-originated constraint @@ -263,7 +258,6 @@ void omap_pm_cpu_set_freq(unsigned long f) * CDP should just be able to set the VDD1 OPP clock rate here. */ } -EXPORT_SYMBOL(omap_pm_cpu_set_freq); unsigned long omap_pm_cpu_get_freq(void) { @@ -275,7 +269,6 @@ unsigned long omap_pm_cpu_get_freq(void) return 0; } -EXPORT_SYMBOL(omap_pm_cpu_get_freq); /* * Device context loss tracking diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c index a28945b..d769b90 100644 --- a/arch/arm/plat-omap/omap-pm-srf.c +++ b/arch/arm/plat-omap/omap-pm-srf.c @@ -185,7 +185,6 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void) return NULL; } -EXPORT_SYMBOL(omap_pm_dsp_get_opp_table); void omap_pm_dsp_set_min_opp(u8 opp_id) { @@ -203,28 +202,24 @@ void omap_pm_dsp_set_min_opp(u8 opp_id) resource_request("vdd1_opp", &dummy_dsp_dev, opp_id); return; } -EXPORT_SYMBOL(omap_pm_dsp_set_min_opp); u8 omap_pm_dsp_get_opp(void) { pr_debug("OMAP PM: DSP requests current DSP OPP ID\n"); return resource_get_level("vdd1_opp"); } -EXPORT_SYMBOL(omap_pm_dsp_get_opp); u8 omap_pm_vdd1_get_opp(void) { pr_debug("OMAP PM: User requests current VDD1 OPP\n"); return resource_get_level("vdd1_opp"); } -EXPORT_SYMBOL(omap_pm_vdd1_get_opp); u8 omap_pm_vdd2_get_opp(void) { pr_debug("OMAP PM: User requests current VDD2 OPP\n"); return resource_get_level("vdd2_opp"); } -EXPORT_SYMBOL(omap_pm_vdd2_get_opp); /* * CPUFreq-originated constraint @@ -261,14 +256,12 @@ void omap_pm_cpu_set_freq(unsigned long f) resource_request("mpu_freq", &dummy_cpufreq_dev, f); return; } -EXPORT_SYMBOL(omap_pm_cpu_set_freq); unsigned long omap_pm_cpu_get_freq(void) { pr_debug("OMAP PM: CPUFreq requests current CPU frequency\n"); return resource_get_level("mpu_freq"); } -EXPORT_SYMBOL(omap_pm_cpu_get_freq); /* * Device context loss tracking -- 1.6.5.GIT -- 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: [ANNOUNCE] updated dspbridge on linux-omap
Hi Paul, >From: Paul Walmsley [mailto:p...@pwsan.com] >Sent: Tuesday, October 27, 2009 2:16 PM > >On Tue, 20 Oct 2009, Ramirez Luna, Omar wrote: > >> Also, DVFS Bridge feature won't compile if rebasing onto PM branch >> because it is missing clk notifier functions. > >This should not break compilation. The DSPBridge code must use >platform_data function pointers to call clock notifier functions. > Agree, we do use platform_data to call DVFS related functions: static struct dspbridge_platform_data dspbridge_pdata __initdata = { #ifdef CONFIG_BRIDGE_DVFS .dsp_set_min_opp = omap_pm_dsp_set_min_opp, .dsp_get_opp = omap_pm_dsp_get_opp, .cpu_set_freq= omap_pm_cpu_set_freq, .cpu_get_freq= omap_pm_cpu_get_freq, #endif }; What I meant is that I couldn't find clk_notifier_* functions in pm-branch others than 2.6.28 and 2.6.29, I'll retry looking for them though, I just assumed that they should be under plat-omap/clocks.c >Also, on a related note, I see that EXPORT_SYMBOL() entries have been >added for many OPP-related functions in plat-omap/omap-pm-*.c. This is >not the right way to do it. These also should be called via platform_data >function pointers. > >Then your code will compile no matter whether the OMAP clock notifier or >OMAP PM patches are present or not. The point here is to keep the device >drivers completely separate from architecture-level code, so you could, >for example, use DSPBridge on a DaVinci platform. > >I will post a patch to remove the EXPORT_SYMBOL() entries from the OMAP PM >code. > > >- Paul - omar -- 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
looking for presence of PMN interrupt in OMAP3530
Hello. I am working on porting a piece of code that makes use of irq on top of the performance counters (PMN) present in the OMAP3530's Cortex A8 MPU. This code is ported from an armv6 platform (arm1176 cpu). On the original platform (pb1176) the interrupt number into the IC was known from the documentation (39). I am unable to find the interrupt number for the performance counters and can not believe the TI people left the line unconnected to the GIC when they build the OMAP3530. I have searched in the TI documentation: Interrupt table (starting on page 1074 in http://focus.ti.com/lit/ug/spruff6b/spruff6b.pdf ) for a suitable entry but did not find it. I have tried to program a counter overflow and unmask the first 4 IRQs in the MPU in the hope that one of these is the PMU irq, again without success. *** Did anybody get into this documentation problem? Did he find a fix for it? Is there a PMN interrupt in the OMAP3530 IC Interrupt table? *** Thank you, Gabi Voiculescu -- 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: SRF: Drop unnecessary powerdomain activity hooks
This patch applies against the PM branch. omap_pm_pwrdm_active() and omap_pm_pwrdm_inactive() were dropped from the OMAP PM interface some time ago, but evidently we did not drop them from omap-pm-srf.c; this patch does that now. Signed-off-by: Paul Walmsley Cc: Rajendra Nayak Cc: Kevin Hilman --- arch/arm/plat-omap/omap-pm-srf.c | 38 +- 1 files changed, 1 insertions(+), 37 deletions(-) diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c index d769b90..ef1d235 100644 --- a/arch/arm/plat-omap/omap-pm-srf.c +++ b/arch/arm/plat-omap/omap-pm-srf.c @@ -297,43 +297,7 @@ int omap_pm_get_dev_context_loss_count(struct device *dev) } /* - * Powerdomain usecounting hooks - */ - -void omap_pm_pwrdm_active(struct powerdomain *pwrdm) -{ - if (!pwrdm) { - WARN_ON(1); - return; - }; - - pr_debug("OMAP PM: powerdomain %s is becoming active\n", pwrdm->name); - - /* -* CDP code apparently will need these for the enable_power_domain() -* and disable_power_domain() functions. -*/ -} - -void omap_pm_pwrdm_inactive(struct powerdomain *pwrdm) -{ - if (!pwrdm) { - WARN_ON(1); - return; - }; - - pr_debug("OMAP PM: powerdomain %s is becoming inactive\n", -pwrdm->name); - - /* -* CDP code apparently will need these for the enable_power_domain() -* and disable_power_domain() functions. -*/ -} - -/* - * Should be called before clk framework since clk fw will call - * omap_pm_pwrdm_{in,}active() + * Must be called before clk framework init */ int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table, struct omap_opp *dsp_opp_table, -- 1.6.5.GIT -- 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 SRF: fix authorship, initial comment
This patch applies against the PM branch. While this code is derived from other code that I wrote, I believe this code was originally written by Rajendra Nayak. Signed-off-by: Paul Walmsley Cc: Rajendra Nayak Cc: Kevin Hilman --- arch/arm/plat-omap/omap-pm-srf.c | 11 --- 1 files changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-pm-srf.c index ef1d235..751d9b3 100644 --- a/arch/arm/plat-omap/omap-pm-srf.c +++ b/arch/arm/plat-omap/omap-pm-srf.c @@ -2,14 +2,11 @@ * omap-pm-srf.c - OMAP power management interface implemented * using Shared resource framework * - * This code implements the OMAP power management interface to - * drivers, CPUIdle, CPUFreq, and DSP Bridge. It is strictly for - * debug/demonstration use, as it does nothing but printk() whenever a - * function is called (when DEBUG is defined, below) + * Copyright (C) 2008-2009 Texas Instruments, Inc. + * Copyright (C) 2008-2009 Nokia Corporation + * Rajendra Nayak * - * Copyright (C) 2008 Texas Instruments, Inc. - * Copyright (C) 2008 Nokia Corporation - * Paul Walmsley + * This code is based on plat-omap/omap-pm-noop.c. * * Interface developed by (in alphabetical order): * Karthik Dasu, Tony Lindgren, Rajendra Nayak, Sakari Poussa, Veeramanikandan -- 1.6.5.GIT -- 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
GPMC setup help
I've been going round and round on this for a couple of days. I have a logic analyzer (cheap USB, that is why come edges are not quite synced) attached to the gpmc pins on a logicpd dev board. The read cycle timings are what I expect. The write cycle seems to do one cycle OK, then thing go into the weeds. Here are the values I write into the registers: GPMC_CONFIG1 reg: 1200 GPMC_CONFIG2 reg: 40400 GPMC_CONFIG3 reg: 20201 GPMC_CONFIG4 reg: 4030403 GPMC_CONFIG5 reg: 1040505 GPMC_CONFIG6 reg: 403 and here is a screen shot of the logic analyzer: http://balister.dyndns.org:8008/~balister/gpmc-write.png Philip -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM: Remove symbol exports
Paul Walmsley writes: > This patch applies against the PM branch. > > Commit b32960d2fd88085d6270c4f3a2f708e7ce42cd7b exported many of the > functions from the OMAP PM layer, presumably to allow device drivers > to call them directly. This ties the device drivers to the OMAP > platform; they will not compile or work on other platforms, e.g., > DaVinci. Device driver code should be platform-independent. This > patch removes the EXPORT_SYMBOL() lines. > > Rather than relying on exported symbols, device drivers should instead > pass pointers to these functions via function pointers in struct > platform_device.platform_data. Then the device driver code should use > an idiom similar to: > >if (pdata->function_name) > pdata->function_name(arg1, arg2, ...); > > Signed-off-by: Paul Walmsley > Cc: Ameya Palande > Cc: Kevin Hilman Thanks, pushing to PM branch. On the next rebase, I'll just drop the commit(s) that added the exports. Kevin > --- > arch/arm/plat-omap/omap-pm-noop.c |7 --- > arch/arm/plat-omap/omap-pm-srf.c |7 --- > 2 files changed, 0 insertions(+), 14 deletions(-) > > diff --git a/arch/arm/plat-omap/omap-pm-noop.c > b/arch/arm/plat-omap/omap-pm-noop.c > index d3c7279..cab105f 100644 > --- a/arch/arm/plat-omap/omap-pm-noop.c > +++ b/arch/arm/plat-omap/omap-pm-noop.c > @@ -157,7 +157,6 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void) > > return NULL; > } > -EXPORT_SYMBOL(omap_pm_dsp_get_opp_table); > > void omap_pm_dsp_set_min_opp(u8 opp_id) > { > @@ -182,7 +181,6 @@ void omap_pm_dsp_set_min_opp(u8 opp_id) >* >*/ > } > -EXPORT_SYMBOL(omap_pm_dsp_set_min_opp); > > u8 omap_pm_dsp_get_opp(void) > { > @@ -198,7 +196,6 @@ u8 omap_pm_dsp_get_opp(void) > > return 0; > } > -EXPORT_SYMBOL(omap_pm_dsp_get_opp); > > u8 omap_pm_vdd1_get_opp(void) > { > @@ -210,7 +207,6 @@ u8 omap_pm_vdd1_get_opp(void) > > return 0; > } > -EXPORT_SYMBOL(omap_pm_vdd1_get_opp); > > u8 omap_pm_vdd2_get_opp(void) > { > @@ -222,7 +218,6 @@ u8 omap_pm_vdd2_get_opp(void) > > return 0; > } > -EXPORT_SYMBOL(omap_pm_vdd2_get_opp); > > /* > * CPUFreq-originated constraint > @@ -263,7 +258,6 @@ void omap_pm_cpu_set_freq(unsigned long f) >* CDP should just be able to set the VDD1 OPP clock rate here. >*/ > } > -EXPORT_SYMBOL(omap_pm_cpu_set_freq); > > unsigned long omap_pm_cpu_get_freq(void) > { > @@ -275,7 +269,6 @@ unsigned long omap_pm_cpu_get_freq(void) > > return 0; > } > -EXPORT_SYMBOL(omap_pm_cpu_get_freq); > > /* > * Device context loss tracking > diff --git a/arch/arm/plat-omap/omap-pm-srf.c > b/arch/arm/plat-omap/omap-pm-srf.c > index a28945b..d769b90 100644 > --- a/arch/arm/plat-omap/omap-pm-srf.c > +++ b/arch/arm/plat-omap/omap-pm-srf.c > @@ -185,7 +185,6 @@ const struct omap_opp *omap_pm_dsp_get_opp_table(void) > > return NULL; > } > -EXPORT_SYMBOL(omap_pm_dsp_get_opp_table); > > void omap_pm_dsp_set_min_opp(u8 opp_id) > { > @@ -203,28 +202,24 @@ void omap_pm_dsp_set_min_opp(u8 opp_id) > resource_request("vdd1_opp", &dummy_dsp_dev, opp_id); > return; > } > -EXPORT_SYMBOL(omap_pm_dsp_set_min_opp); > > u8 omap_pm_dsp_get_opp(void) > { > pr_debug("OMAP PM: DSP requests current DSP OPP ID\n"); > return resource_get_level("vdd1_opp"); > } > -EXPORT_SYMBOL(omap_pm_dsp_get_opp); > > u8 omap_pm_vdd1_get_opp(void) > { > pr_debug("OMAP PM: User requests current VDD1 OPP\n"); > return resource_get_level("vdd1_opp"); > } > -EXPORT_SYMBOL(omap_pm_vdd1_get_opp); > > u8 omap_pm_vdd2_get_opp(void) > { > pr_debug("OMAP PM: User requests current VDD2 OPP\n"); > return resource_get_level("vdd2_opp"); > } > -EXPORT_SYMBOL(omap_pm_vdd2_get_opp); > > /* > * CPUFreq-originated constraint > @@ -261,14 +256,12 @@ void omap_pm_cpu_set_freq(unsigned long f) > resource_request("mpu_freq", &dummy_cpufreq_dev, f); > return; > } > -EXPORT_SYMBOL(omap_pm_cpu_set_freq); > > unsigned long omap_pm_cpu_get_freq(void) > { > pr_debug("OMAP PM: CPUFreq requests current CPU frequency\n"); > return resource_get_level("mpu_freq"); > } > -EXPORT_SYMBOL(omap_pm_cpu_get_freq); > > /* > * Device context loss tracking > -- > 1.6.5.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM: SRF: Drop unnecessary powerdomain activity hooks
Paul Walmsley writes: > This patch applies against the PM branch. > > omap_pm_pwrdm_active() and omap_pm_pwrdm_inactive() were dropped from the > OMAP PM interface some time ago, but evidently we did not drop them from > omap-pm-srf.c; this patch does that now. > > Signed-off-by: Paul Walmsley > Cc: Rajendra Nayak > Cc: Kevin Hilman Thanks, pushing to PM branch. Kevin > --- > arch/arm/plat-omap/omap-pm-srf.c | 38 > +- > 1 files changed, 1 insertions(+), 37 deletions(-) > > diff --git a/arch/arm/plat-omap/omap-pm-srf.c > b/arch/arm/plat-omap/omap-pm-srf.c > index d769b90..ef1d235 100644 > --- a/arch/arm/plat-omap/omap-pm-srf.c > +++ b/arch/arm/plat-omap/omap-pm-srf.c > @@ -297,43 +297,7 @@ int omap_pm_get_dev_context_loss_count(struct device > *dev) > } > > /* > - * Powerdomain usecounting hooks > - */ > - > -void omap_pm_pwrdm_active(struct powerdomain *pwrdm) > -{ > - if (!pwrdm) { > - WARN_ON(1); > - return; > - }; > - > - pr_debug("OMAP PM: powerdomain %s is becoming active\n", pwrdm->name); > - > - /* > - * CDP code apparently will need these for the enable_power_domain() > - * and disable_power_domain() functions. > - */ > -} > - > -void omap_pm_pwrdm_inactive(struct powerdomain *pwrdm) > -{ > - if (!pwrdm) { > - WARN_ON(1); > - return; > - }; > - > - pr_debug("OMAP PM: powerdomain %s is becoming inactive\n", > - pwrdm->name); > - > - /* > - * CDP code apparently will need these for the enable_power_domain() > - * and disable_power_domain() functions. > - */ > -} > - > -/* > - * Should be called before clk framework since clk fw will call > - * omap_pm_pwrdm_{in,}active() > + * Must be called before clk framework init > */ > int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table, >struct omap_opp *dsp_opp_table, > -- > 1.6.5.GIT -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP PM SRF: fix authorship, initial comment
Paul Walmsley writes: > This patch applies against the PM branch. > > While this code is derived from other code that I wrote, I believe this code > was originally written by Rajendra Nayak. > > Signed-off-by: Paul Walmsley > Cc: Rajendra Nayak > Cc: Kevin Hilman Thanks, pushing to PM branch. Upon rebase, will fold into initial addion of SRF. Kevin > --- > arch/arm/plat-omap/omap-pm-srf.c | 11 --- > 1 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/plat-omap/omap-pm-srf.c > b/arch/arm/plat-omap/omap-pm-srf.c > index ef1d235..751d9b3 100644 > --- a/arch/arm/plat-omap/omap-pm-srf.c > +++ b/arch/arm/plat-omap/omap-pm-srf.c > @@ -2,14 +2,11 @@ > * omap-pm-srf.c - OMAP power management interface implemented > * using Shared resource framework > * > - * This code implements the OMAP power management interface to > - * drivers, CPUIdle, CPUFreq, and DSP Bridge. It is strictly for > - * debug/demonstration use, as it does nothing but printk() whenever a > - * function is called (when DEBUG is defined, below) > + * Copyright (C) 2008-2009 Texas Instruments, Inc. > + * Copyright (C) 2008-2009 Nokia Corporation > + * Rajendra Nayak > * > - * Copyright (C) 2008 Texas Instruments, Inc. > - * Copyright (C) 2008 Nokia Corporation > - * Paul Walmsley > + * This code is based on plat-omap/omap-pm-noop.c. > * > * Interface developed by (in alphabetical order): > * Karthik Dasu, Tony Lindgren, Rajendra Nayak, Sakari Poussa, > Veeramanikandan > -- > 1.6.5.GIT -- 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] AM35xx: Runtime detection of the device
Hi, On Tue, Oct 27, 2009 at 07:08:22PM +0100, ext Premi, Sanjeev wrote: > > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > > > index 1c15112..87efb73 100644 > > > --- a/arch/arm/mach-omap2/id.c > > > +++ b/arch/arm/mach-omap2/id.c > > > @@ -242,6 +242,21 @@ void __init omap3_check_revision(void) > > > omap_revision = OMAP3630_REV_ES1_0; > > > } > > > break; > > > + case 0xb868: > > > + /* Handle OMAP35xx/AM35xx devices > > > + * > > > + * Set the device to be OMAP3517 here. Actual device > > > + * is identified later based on the features. > > > + */ > > > + switch (rev) { > > > + case 0: > > > + omap_revision = OMAP3505_REV(rev); > > > + break; > > > + default: > > > + /* Use the latest known revision as default */ > > > + omap_revision = OMAP3505_REV(rev); > > > > if both are the same, what's the point of having this switch ? > > [sp] I was just following the style for 3630, while re-basing > this patch :( I see, but that's clearly bogus (in a sense), then if you come up with another version of the chip, there will be two place to be fixed. Tony, what do you think about applying the following cleanup patch to id.c ? From: Felipe Balbi Subject: [PATCH] arm: omap: code cleanup to id.c Cleanup the coding style in id.c while avoiding unneeded switch() statements. Signed-off-by: Felipe Balbi --- diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 1c15112..dbdeb09 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -53,11 +53,11 @@ int omap_type(void) { u32 val = 0; - if (cpu_is_omap24xx()) + if (cpu_is_omap24xx()) { val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS); - else if (cpu_is_omap34xx()) + } else if (cpu_is_omap34xx()) { val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS); - else { + } else { pr_err("Cannot detect omap type!\n"); goto out; } @@ -224,24 +224,14 @@ void __init omap3_check_revision(void) omap_revision = OMAP3430_REV_ES3_0; break; case 4: - omap_revision = OMAP3430_REV_ES3_1; - break; + /* FALLTHROUGH */ default: /* Use the latest known revision as default */ omap_revision = OMAP3430_REV_ES3_1; } break; case 0xb891: - /* Handle 36xx devices */ - switch (rev) { - case 0: - omap_revision = OMAP3630_REV_ES1_0; - break; - default: - /* Use the latest known revision as default */ - omap_revision = OMAP3630_REV_ES1_0; - } - break; + /* FALLTHROUGH */ default: /* Unknown default to latest silicon rev as default*/ omap_revision = OMAP3630_REV_ES1_0; @@ -266,19 +256,17 @@ void __init omap3_cpuinfo(void) * on available features. Upon detection, update the CPU id * and CPU class bits. */ - if (cpu_is_omap3630()) + if (cpu_is_omap3630()) { strcpy(cpu_name, "3630"); - else if (omap3_has_iva() && omap3_has_sgx()) + } else if (omap3_has_iva() && omap3_has_sgx()) { strcpy(cpu_name, "3430/3530"); - else if (omap3_has_sgx()) { + } else if (omap3_has_sgx()) { omap_revision = OMAP3525_REV(rev); strcpy(cpu_name, "3525"); - } - else if (omap3_has_iva()) { + } else if (omap3_has_iva()) { omap_revision = OMAP3515_REV(rev); strcpy(cpu_name, "3515"); - } - else { + } else { omap_revision = OMAP3503_REV(rev); strcpy(cpu_name, "3503"); } @@ -297,8 +285,7 @@ void __init omap3_cpuinfo(void) strcpy(cpu_rev, "3.0"); break; case OMAP_REVBITS_40: - strcpy(cpu_rev, "3.1"); - break; + /* FALLTHROUGH */ default: /* Use the latest known revision as default */ strcpy(cpu_rev, "3.1"); @@ -325,18 +312,18 @@ void __init omap2_check_revision(void) * At this point we have an idea about the processor revision set * earlier with omap2_set_globals_tap(). */ - if (cpu_is_omap24xx()) + if (cpu_is_omap24xx()) { omap24xx_check_revision(); - else if (cpu_is_omap34xx()) { + } else if (cpu_is_omap34xx()) { omap3_check_features(); omap3_check_revision(); omap3_cpuinfo(); - } - else if (cpu_
RE: [PATCH 3/3] omap: zoom3: add zoom3 board support
>-Original Message- >From: Felipe Balbi [mailto:m...@felipebalbi.com] >Sent: Friday, October 23, 2009 6:04 PM >To: Pandita, Vikram >Cc: linux-omap@vger.kernel.org >Subject: Re: [PATCH 3/3] omap: zoom3: add zoom3 board support > >Hi, > >On Fri, Oct 23, 2009 at 02:23:26PM -0500, Vikram Pandita wrote: >> diff --git a/arch/arm/mach-omap2/board-zoom2-zoom3.c >> b/arch/arm/mach-omap2/board-zoom2-zoom3.c >> index 4ad9b94..d806dbf 100644 >> --- a/arch/arm/mach-omap2/board-zoom2-zoom3.c >> +++ b/arch/arm/mach-omap2/board-zoom2-zoom3.c >> @@ -281,7 +281,11 @@ static void __init omap_zoom2_map_io(void) >> omap2_map_common_io(); >> } >> >> +#ifdef CONFIG_MACH_OMAP_ZOOM3 >> +MACHINE_START(OMAP_ZOOM3, "OMAP ZOOM3 board") >> +#else >> MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board") >> +#endif > >what happens if you want to build a kernel for both boards ? > >how about just adding a new MACHINE_START() declaration without >ifdeferry ? > >Take a look at arch/arm/mach-omap2/board-n8x0.c for an example ;-) Yes I will have a look at this. Thanks for all the comments. My zoom3 board has gone bad and so could not look into this yet. Will keep posted. > >-- >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
[PATCH]Set omap3630 MMC1 I/O speed to 52Mhz
>From 43454c1812043ca6b21d2594e63c93b6250a9882 Mon Sep 17 00:00:00 2001 From: Madhu Date: Tue, 27 Oct 2009 17:44:09 -0400 Subject: [PATCH]Set omap3630 MMC1 I/O speed to 52Mhz The speed ctrl bit for MMC I/O is part of CONTROL_PROG_IO1 register in omap3630.This patch sets it up accordingly. Signed-off-by: Madhusudhan Chikkature --- arch/arm/mach-omap2/mmc-twl4030.c | 11 +-- arch/arm/plat-omap/include/plat/control.h |4 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-omap2/mmc-twl4030.c index 7bef170..1940591 100644 --- a/arch/arm/mach-omap2/mmc-twl4030.c +++ b/arch/arm/mach-omap2/mmc-twl4030.c @@ -213,7 +213,7 @@ static int twl4030_mmc_get_context_loss(struct device *dev) static int twl_mmc1_set_power(struct device *dev, int slot, int power_on, int vdd) { - u32 reg; + u32 reg, prog_io; int ret = 0; struct twl_mmc_controller *c = &hsmmc[0]; struct omap_mmc_platform_data *mmc = dev->platform_data; @@ -245,7 +245,14 @@ static int twl_mmc1_set_power(struct device *dev, int slot, int power_on, } reg = omap_ctrl_readl(control_pbias_offset); - reg |= OMAP2_PBIASSPEEDCTRL0; + if (cpu_is_omap3630()) { + /* Set MMC I/O to 52Mhz */ + prog_io = omap_ctrl_readl(OMAP34XX_CONTROL_PROG_IO1); + prog_io |= OMAP3630_PRG_SDMMC1_SPEEDCTRL; + omap_ctrl_writel(prog_io, OMAP34XX_CONTROL_PROG_IO1); + } else { + reg |= OMAP2_PBIASSPEEDCTRL0; + } reg &= ~OMAP2_PBIASLITEPWRDNZ0; omap_ctrl_writel(reg, control_pbias_offset); diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h index fdb6300..47368bc 100644 --- a/arch/arm/plat-omap/include/plat/control.h +++ b/arch/arm/plat-omap/include/plat/control.h @@ -146,6 +146,7 @@ #define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194) #define OMAP343X_CONTROL_PBIAS_LITE(OMAP2_CONTROL_GENERAL + 0x02b0) #define OMAP343X_CONTROL_TEMP_SENSOR (OMAP2_CONTROL_GENERAL + 0x02b4) +#define OMAP34XX_CONTROL_PROG_IO1 (OMAP2_CONTROL_GENERAL + 0x01D8) /* 34xx D2D idle-related pins, handled by PM core */ #define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250 @@ -196,6 +197,9 @@ #define OMAP2_PBIASLITEPWRDNZ0 (1 << 1) #define OMAP2_PBIASLITEVMODE0 (1 << 0) +/* CONTROL_PROG_IO1 bits */ +#define OMAP3630_PRG_SDMMC1_SPEEDCTRL (1 << 20) + /* CONTROL_IVA2_BOOTMOD bits */ #define OMAP3_IVA2_BOOTMOD_SHIFT 0 #define OMAP3_IVA2_BOOTMOD_MASK(0xf << 0) -- 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
Hello Nishanth, Manjunath, a comment on cpu_relax() and udelay(). On Mon, 26 Oct 2009, Menon, Nishanth wrote: > > -Original Message- > > From: G, Manjunath Kondaiah > > > > As per your comments for other patches when ever there is udelay usage, > > cpu_relax is the better option. I see there are lot of udelay(...) calls > > used in this patch. Why can't you use cpu_relax() or schedule(). > > Any specific reason? > > > Don’t really want to do cpu_relax in irq_locked context.. There are no restrictions on the calling context for cpu_relax(). [ schedule(), of course, does have restrictions. ] I don't understand the use of the udelay(10). Could you please explain this further? Is it the case that if the register bit doesn't change within 50 reads, that it is then not likely to change for 10 microseconds? If that isn't how the device works, then using udelay(10) will just waste power busy-looping in the CPU. I would rather see this code using udelay(1) between each register read if you want to ensure that you read the register for at least 50 microseconds. This would also simplify your timeout loops considerably, which seem unnecessarily complicated. But if the scenario above is how the device is expected to respond, then these loops should have some comments to explain why the extra complexity and power consumption of a 10 microsecond busy-loop after every 50 reads is the right thing to do. regards, - Paul
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> ow...@vger.kernel.org] On Behalf Of Kalle Jokiniemi > Sent: Tuesday, October 27, 2009 5:14 PM > > Hi Nishanth, > > Found some dead code, see below: [...] > > +/* T2 SMART REFLEX */ > > +#define R_SRI2C_SLAVE_ADDR 0x12 > > +#define R_VDD1_SR_CONTROL 0x00 > > +#define R_VDD2_SR_CONTROL 0x01 > > + > > +/* VDDs*/ > > +#define PRCM_VDD1 1 > > +#define PRCM_VDD2 2 > > + > > This comment below can be removed, provided that you apply my other > comments. > > > +/* > > + * XXX: These should be removed/moved from here once we have a working > DVFS > > + * implementation in place > > + */ > > +#define PHY_TO_OFF_PM_MASTER(p)(p - 0x36) > > No need for PHY_TO_OFF_PM_MASTER definition. Remove that. > > > > +#define PHY_TO_OFF_PM_RECIEVER(p) (p - 0x5b) > > +#define PHY_TO_OFF_PM_INT(p) (p - 0x2e) > > No need for PHY_TO_OFF_PM_INT def. Remove. > > > + > > +/* Vmode control */ > > +#define R_DCDC_GLOBAL_CFG PHY_TO_OFF_PM_RECIEVER(0x61) > > +/* R_DCDC_GLOBAL_CFG register, SMARTREFLEX_ENABLE values */ > > +#define DCDC_GLOBAL_CFG_ENABLE_SRFLX 0x08 > > > As we now have other ways of determining opp, remove code from here... > > > + > > +/* DEVICE ID/DPLL ID/CLOCK ID: bits 28-31 for OMAP type */ > > +#define OMAP_TYPE_SHIFT28 > > +#define OMAP_TYPE_MASK 0xF > > +/* OPP ID: bits: 0-4 for OPP number */ > > +#define OPP_NO_POS 0 > > +#define OPP_NO_MASK0x1F > > +/* OPP ID: bits: 5-6 for VDD */ > > +#define VDD_NO_POS 5 > > +#define VDD_NO_MASK0x3 > > +/* Other IDs: bits 20-27 for ID type */ > > +/* These IDs have bits 25,26,27 as 1 */ > > +#define OTHER_ID_TYPE_SHIFT20 > > +#define OTHER_ID_TYPE_MASK 0xFF > > + > > +#define OTHER_ID_TYPE(X) ((X & OTHER_ID_TYPE_MASK) << > OTHER_ID_TYPE_SHIFT) > > +#define ID_OPP_NO(X)((X & OPP_NO_MASK) << OPP_NO_POS) > > +#define ID_VDD(X) ((X & VDD_NO_MASK) << VDD_NO_POS) > > +#define OMAP(X) ((X >> OMAP_TYPE_SHIFT) & > OMAP_TYPE_MASK) > > +#define get_opp_no(X) ((X >> OPP_NO_POS) & OPP_NO_MASK) > > +#define get_vdd(X) ((X >> VDD_NO_POS) & VDD_NO_MASK) > > + > > +/* XXX: end remove/move */ > > + > > +/* XXX: find more appropriate place for these once DVFS is in place */ > > +extern u32 current_vdd1_opp; > > +extern u32 current_vdd2_opp; > > ...to here. > > At least with a quick glance, it seems the above defs are not in use. > Your compiler should tell if I missed something ;) Thanks... will fix in my rev 5. Regards, Nishanth Menon N�r��yb�X��ǧv�^�){.n�+{��f��{ay�ʇڙ�,j��f���h���z��w��� ���j:+v���w�j�mzZ+�ݢj"��!�i
RE: [PATCH 2/2 v3] OMAP3: PM: SR: SmartReflex Refactor Rev4.0
> -Original Message- > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Wednesday, October 28, 2009 1:37 AM > [..] > a comment on cpu_relax() and udelay(). > > On Mon, 26 Oct 2009, Menon, Nishanth wrote: > > > > -Original Message- > > > From: G, Manjunath Kondaiah > > > > > > As per your comments for other patches when ever there is udelay usage, > > > cpu_relax is the better option. I see there are lot of udelay(...) > calls > > > used in this patch. Why can't you use cpu_relax() or schedule(). > > > Any specific reason? > > > > > Don’t really want to do cpu_relax in irq_locked context.. > > There are no restrictions on the calling context for cpu_relax(). > [ schedule(), of course, does have restrictions. ] Thanks.. > > I don't understand the use of the udelay(10). Could you please explain > this further? Is it the case that if the register bit doesn't change > within 50 reads, that it is then not likely to change for 10 microseconds? The delay of 10 used is in vcbypass command -> the loop actually waits for the i2c command to get thru.. depending on the speed of the bus configured and cpu speed, 50 iterations might not be enough, but yes, a udelay(1) loop in addition to cpu_relax might be better.. > > If that isn't how the device works, then using udelay(10) will just waste > power busy-looping in the CPU. I would rather see this code using > udelay(1) between each register read if you want to ensure that you read > the register for at least 50 microseconds. This would also simplify your > timeout loops considerably, which seem unnecessarily complicated. Ack. 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: [alsa-devel] [PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Tuesday 27 October 2009 16:00:00 ext Jarkko Nikula wrote: > On Tue, 27 Oct 2009 13:07:23 +0200 > > Eero Nurkkala wrote: > > Otherwise, that spinlocking is highly unnecessary and things are > > far better without than with it. The only case it could be useful > > is in SMPs, but OMAPs are not such quite yet - and when they > > are, things will need to be re-though anyway. > > Following commit is suggesting that mcbsp code *must* be SMP safe > already now: > > commit a5b92cc348299c20be215b9f4b50853ecfbf3864 > Author: Syed Rafiuddin > Date: Tue Jul 28 18:57:10 2009 +0530 > > ARM: OMAP4: Add McBSP support Yeah, but I think this locking issue has nothing to do with SMP safe or not. On playback start in omap_mcbsp_request the mcbsp->free is cleared. Further modification to the dma_op_mode in dma_op_mode_store is not allowed if the mcbsp port is in use, thus the dma_op_mode is protected against change while the port is in use (ensuring that the mode is same in omap34xx_mcbsp_request and omap_mcbsp_get_dma_op_mode functions). This alone makes the use of spinlock around the dma_op_mode unnecessary. -- Péter -- 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] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode
On Wed, 2009-10-28 at 06:52 +0100, Ujfalusi Peter (Nokia-D/Tampere) wrote: > On Tuesday 27 October 2009 16:00:00 ext Jarkko Nikula wrote: > > On Tue, 27 Oct 2009 13:07:23 +0200 > > > > Eero Nurkkala wrote: > > > Otherwise, that spinlocking is highly unnecessary and things are > > > far better without than with it. The only case it could be useful > > > is in SMPs, but OMAPs are not such quite yet - and when they > > > are, things will need to be re-though anyway. > > > > Following commit is suggesting that mcbsp code *must* be SMP safe > > already now: > > > > commit a5b92cc348299c20be215b9f4b50853ecfbf3864 > > Author: Syed Rafiuddin > > Date: Tue Jul 28 18:57:10 2009 +0530 > > > > ARM: OMAP4: Add McBSP support > > Yeah, but I think this locking issue has nothing to do with SMP safe or not. > On playback start in omap_mcbsp_request the mcbsp->free is cleared. > Further modification to the dma_op_mode in dma_op_mode_store is not allowed > if > the mcbsp port is in use, thus the dma_op_mode is protected against change > while > the port is in use (ensuring that the mode is same in omap34xx_mcbsp_request > and > omap_mcbsp_get_dma_op_mode functions). This alone makes the use of spinlock > around the dma_op_mode unnecessary. > Yeah, maybe I took the SMP safeness into play without looking any code, my bad =) I was remembering a different version of this McBSP thing, now that I looked into it, it looked different. Right, I reviewed the code, and it was first looking really bad at sound/soc/omap/omap-mcbsp.c, where it calls omap_mcbsp_get_dma_op_mode() from different places. However, it's not an issue because in: arch/arm/plat-omap/mcbsp.c : dma_op_mode_store(), the dma_op_mode is written only if the mcbsp is unoccupied. So it is SMP safe. ..and a single read is always atomic, so this is buggy code: 301 spin_lock_irq(&mcbsp->lock); 302 dma_op_mode = mcbsp->dma_op_mode; 303 spin_unlock_irq(&mcbsp->lock); 304 305 return dma_op_mode; The spinlocks are unnecessary. In the above example, you get the same with just "return mcbsp->dma_op_mode;" -> Peter's patch is a good cleanup. -- 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