[PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode

2009-10-27 Thread Peter Ujfalusi 
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 peter.ujfal...@nokia.com
---
 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

2009-10-27 Thread Eero Nurkkala 
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 peter.ujfal...@nokia.com
 ---

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

2009-10-27 Thread Peter Ujfalusi 
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 peter.ujfal...@nokia.com
  ---
 
 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

2009-10-27 Thread Imberton Guilhem-gimb01 
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 : [c004e23c]lr : [c004f544]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

Re: [alsa-devel] [PATCH] OMAP: McBSP: Do not use extensive spin locks for dma_op_mode

2009-10-27 Thread Mark Brown 
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

2009-10-27 Thread Dasgupta, Romit 
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] [c002b87c] (unwind_backtrace+0x0/0xdc) from [c004ff58] 
(warn_slowpath_common+0x48/0x60)
[  113.785705] [c004ff58] (warn_slowpath_common+0x48/0x60) from [c004ffa8] 
(warn_slowpath_fmt+0x24/0x30)
[  113.799896] [c004ffa8] (warn_slowpath_fmt+0x24/0x30) from [c01b36b8] 
(device_pm_add+0x94/0xdc)
[  113.808990] [c01b36b8] (device_pm_add+0x94/0xdc) from [c01ad9bc] 
(device_add+0x3a8/0x534)
[  113.817565] [c01ad9bc] (device_add+0x3a8/0x534) from [c01adbd8] 
(device_create_vargs+0x78/0xa8)
[  113.829650] [c01adbd8] (device_create_vargs+0x78/0xa8) from [c0090a9c] 
(bdi_register+0x3c/0x154)
[  113.839263] [c0090a9c] (bdi_register+0x3c/0x154) from [c0090bd4] 
(bdi_register_dev+0x20/0x28)
[  113.851348] [c0090bd4] (bdi_register_dev+0x20/0x28) from [c0173b98] 
(add_disk+0xe4/0x124)
[  113.859954] [c0173b98] (add_disk+0xe4/0x124) from [c01e6b54] 
(mmc_blk_probe+0x250/0x288)
[  113.870513] [c01e6b54] (mmc_blk_probe+0x250/0x288) from [c01e14d4] 
(mmc_bus_probe+0x18/0x1c)
[  113.879394] [c01e14d4] (mmc_bus_probe+0x18/0x1c) from [c01af97c] 
(driver_probe_device+0xa0/0x14c)
[  113.893890] [c01af97c] (driver_probe_device+0xa0/0x14c) from [c01aef44] 
(bus_for_each_drv+0x44/0x80)
[  113.905609] [c01aef44] (bus_for_each_drv+0x44/0x80) from [c01afb60] 
(device_attach+0x50/0x68)
[  113.914550] [c01afb60] (device_attach+0x50/0x68) from [c01aed94] 
(bus_probe_device+0x24/0x40)
[  113.925170] [c01aed94] (bus_probe_device+0x24/0x40) from [c01ad9f0] 
(device_add+0x3dc/0x534)
[  113.934082] [c01ad9f0] (device_add+0x3dc/0x534) from [c01e1688] 
(mmc_add_card+0xcc/0x118)
[  113.945251] [c01e1688] (mmc_add_card+0xcc/0x118) from [c01e2408] 
(mmc_attach_mmc+0xdc/0x13c)
[  113.954132] [c01e2408] (mmc_attach_mmc+0xdc/0x13c) from [c01e12f0] 
(mmc_rescan+0x2b0/0x2e8)
[  113.964874] [c01e12f0] (mmc_rescan+0x2b0/0x2e8) from [c0060840] 
(worker_thread+0x16c/0x218)
[  113.973693] [c0060840] (worker_thread+0x16c/0x218) from [c0063d88] 
(kthread+0x7c/0x84)
[  113.986694] [c0063d88] (kthread+0x7c/0x84) from [c0026ea0] 
(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 ro...@ti.com
---
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

2009-10-27 Thread Peter Ujfalusi 
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

2009-10-27 Thread Eero Nurkkala 
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

2009-10-27 Thread Tero.Kristo 
 

-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 tero.kri...@nokia.com writes:

 From: Tero Kristo tero.kri...@nokia.com

 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

2009-10-27 Thread Tero Kristo 
From: Tero Kristo tero.kri...@nokia.com

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 tero.kri...@nokia.com
Cc: Samu Onkalo samu.p.onk...@nokia.com
Cc: Kalle Jokiniemi kalle.jokini...@digia.com
Cc: Lauri Leukkunen lauri.leukku...@nokia.com
Cc: Juha Yrjola juha.yrj...@solidboot.com
---
 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 lauri.leukku...@nokia.com
+ *
+ * Original code by Juha Yrjola juha.yrj...@solidboot.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+
+#include plat/io.h
+#include plat/common.h
+#include plat/clock.h
+#include plat/sdrc.h
+
+
+/* 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

Re: [linux-pm] [PATCH] PM: Fixes warning on suspend errors

2009-10-27 Thread Alan Stern 
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 ro...@ti.com
 ---
 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

2009-10-27 Thread Jarkko Nikula 
On Tue, 27 Oct 2009 13:07:23 +0200
Eero Nurkkala ext-eero.nurkk...@nokia.com 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 rafiuddin.s...@ti.com
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

2009-10-27 Thread Sanjeev Premi 
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-omapm=125615009412281w=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

2009-10-27 Thread Sanjeev Premi 
Add support to detect AM3505/AM3517 devices at runtime.
Also updates the CPU names printed during boot.

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 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_omap3517()
 # undef

[PATCH 2/2] AM35xx: Define the AM3517EVM board

2009-10-27 Thread Sanjeev Premi 
Add support for the AM3517 EVM board. This EVM
supports AM3505 and AM3517 devices.

Signed-off-by: Sanjeev Premi pr...@ti.com
---
 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

2009-10-27 Thread Dasgupta, Romit 
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 ro...@ti.com
---

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 ro...@ti.com
  ---
  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

2009-10-27 Thread Felipe Balbi 
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 pr...@ti.com
 ---
  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

2009-10-27 Thread Premi, Sanjeev 
 -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 pr...@ti.com
 ---
  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_omap3430()
  # define cpu_is_omap3503 (cpu_is_omap3430()
   \
   
 (!omap3_has_iva())  \
 @@ -391,6

RE: [PATCH 1/2] AM35xx: Runtime detection of the device

2009-10-27 Thread Premi, Sanjeev 
 -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 pr...@ti.com
  ---
   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

2009-10-27 Thread Paul Walmsley 
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

2009-10-27 Thread Paul Walmsley 

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 p...@pwsan.com
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 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

2009-10-27 Thread Ramirez Luna, Omar 
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

2009-10-27 Thread Gabi Voiculescu 
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

2009-10-27 Thread Paul Walmsley 

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 p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 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

2009-10-27 Thread Paul Walmsley 

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 p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 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

2009-10-27 Thread Philip Balister 
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

2009-10-27 Thread Kevin Hilman 
Paul Walmsley p...@pwsan.com 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 p...@pwsan.com
 Cc: Ameya Palande ameya.pala...@nokia.com
 Cc: Kevin Hilman khil...@deeprootsystems.com

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

2009-10-27 Thread Kevin Hilman 
Paul Walmsley p...@pwsan.com 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 p...@pwsan.com
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Kevin Hilman khil...@deeprootsystems.com

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

2009-10-27 Thread Kevin Hilman 
Paul Walmsley p...@pwsan.com 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 p...@pwsan.com
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Kevin Hilman khil...@deeprootsystems.com

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

2009-10-27 Thread Felipe Balbi 
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 felipe.ba...@nokia.com
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 felipe.ba...@nokia.com
---

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_is_omap44xx()) {
+   } else if

RE: [PATCH 3/3] omap: zoom3: add zoom3 board support

2009-10-27 Thread Pandita, Vikram 


-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

2009-10-27 Thread Madhusudhan Chikkature 
From 43454c1812043ca6b21d2594e63c93b6250a9882 Mon Sep 17 00:00:00 2001
From: Madhu madhu...@ti.com
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 madhu...@ti.com
---
 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

2009-10-27 Thread Paul Walmsley 
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

2009-10-27 Thread Menon, Nishanth 
 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

2009-10-27 Thread Menon, Nishanth 
 -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

2009-10-27 Thread Peter Ujfalusi 
On Tuesday 27 October 2009 16:00:00 ext Jarkko Nikula wrote:
 On Tue, 27 Oct 2009 13:07:23 +0200
 
 Eero Nurkkala ext-eero.nurkk...@nokia.com 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 rafiuddin.s...@ti.com
 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