Re: [PATCH] OMAP2+: SR Layer Cleanup.
Hi, On Wed, Apr 6, 2011 at 9:03 PM, Kevin Hilman khil...@ti.com wrote: Hi Shweta, Shweta Gulati shweta.gul...@ti.com writes: As a part of Voltage Layer Cleanup Patches, submitted by Kevin Hilman, Voltage domain Information is removed from hwmod, So the patch removes 'vdd_name' info from omap_hwmod and adds that info into dev_attr as SR code uses vdd_name to get voltagedomain sructure info. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Thanks for this. It looks good. --- It apllies over Voltage Layer Cleanup Patch by Kevin Hilman: https://patchwork.kernel.org/patch/657421/ Can you rebase on top of my pm-wip/voltdm_a branch? It currently doesn't apply there because the some of the voltage domain names were changed, e.g. mpu - mpu_iva, wkup - wakeup. Ok, I will do. Thanks. Thanks, Kevin -- Thanks, Regards, Shweta -- 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 v2] OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.
On Wed, Apr 06, 2011 at 11:28:00AM +0530, Gulati, Shweta wrote: Hi, On Tue, Apr 5, 2011 at 9:10 PM, Avinash.H.M avinas...@ti.com wrote: GPIO module expects the debounce clocks to be enabled during reset. It doesn't reset properly and timeouts are seen, if this clock isn't enabled during reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with which the debounce clocks are enabled during reset. Minor comment, Rephrase as GPIO module doesn't reset properly and timeouts are seen during bootup, if debounce clock is not enabled to make commit log more clear. Hi Shweta , thanks for the review. i will fix the rephrase the change log . br , - avinash Cc: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Signed-off-by: Avinash.H.M avinas...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
Date: Thu, 7 Apr 2011 12:12:37 +0530
From: Mahadeva, Avinash avinas...@ti.com
To: Kevin Hilman khil...@ti.com
Cc: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org,
Rajendra Nayak rna...@ti.com, Paul Walmsley p...@pwsan.com,
Benoit Cousson b-cous...@ti.com
Subject: Re: [PATCH 1/2 v2] OMAP2/3: hwmod: fix the i2c-reset timeout during
bootup
On Tue, Apr 5, 2011 at 11:57 PM, Kevin Hilman khil...@ti.com wrote:
Avinash.H.M avinas...@ti.com writes:
The i2c module has a special reset sequence. The sequence is
- Disable the I2C.
- Write to SOFTRESET bit.
- Enable the I2C.
- Poll on the RESETDONE bit.
This sequence must be followed for i2c reset in omap2, omap3. The
sequence is
implemented as a function and the i2c_class is updated with the correct
'reset' pointer.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
[...]
+
+/**
+ * omap_i2c_reset- reset the omap i2c module.
+ * @oh: struct omap_hwmod *
+ *
+ * The i2c moudle in omap2, omap3 had a special sequence to reset. The
+ * sequence is:
+ * - Disable the I2C.
+ * - Write to SOFTRESET bit.
+ * - Enable the I2C.
+ * - Poll on the RESETDONE bit.
+ * The sequence is implemented in below function. This is called for
2420,
+ * 2430 and omap3.
+ */
+int omap_i2c_reset(struct omap_hwmod *oh)
+{
+ u32 v;
+ int c = 0;
+
+ /* Disable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v = v ~I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Write to the SOFTRESET bit */
+ v = oh-_sysc_cache;
+ v |= (0x1 oh-class-sysc-sysc_fields-srst_shift);
+
+ oh-_sysc_cache = v;
+ omap_hwmod_write(v, oh, oh-class-sysc-sysc_offs);
Direct SYSCONFIG access isn't right here. This should go through
omap_hwmod.
What is probably needed is exposing _ocp_softreset to device code
via something like omap_hwmod_ocp_softreset() and calling that here.
* Sorry, somehow the mail bounced from l-o. Resending it agian. *
Hi Kevin ,
thanks for the review.
OK. I ll create a wrapper function ' omap_hwmod_ocp_softreset'
around '_ocp_softreset' and call it here .
b r ,
- avinash.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/2] isp1704_charger: fix powering for N900
Hello Anton, Will you take my patch set in, it has been acked by Heikki, and there has been no more comments to be fixed. - Kalle -Original Message- From: Kalle Jokiniemi [mailto:kalle.jokini...@nokia.com] Sent: 29. maaliskuuta 2011 16:28 To: linux-...@vger.kernel.org; cbouatmai...@gmail.com Cc: ba...@ti.com; Krogerus Heikki (Nokia-MS/Helsinki); sshtyl...@mvista.com; t...@atomide.com; khil...@ti.com; linux-omap@vger.kernel.org; jhnik...@gmail.com; Jokiniemi Kalle (Nokia-MS/Tampere) Subject: [PATCH v3 0/2] isp1704_charger: fix powering for N900 This patch set enables powering down the isp1704 usb tranceiver when not in use. tested on RX-51 and MeeGo. Thanks to Felipe Balbi, Sergei Shtylyov, and Heikki Krogerus for comments. v3: * fixed power down handling in isp1704_charger_probe * removed init_done variable * changed BUG_ON to WARN_ON * editorial fixes v2: fixed boot issue in the 1/2 patch. Kalle Jokiniemi (2): isp1704_charger: allow board specific powering routine RX-51: Enable isp1704 power on/off arch/arm/mach-omap2/board-rx51-peripherals.c | 27 ++- drivers/power/isp1704_charger.c | 22 +++ include/linux/power/isp1704_charger.h| 29 ++ 3 files changed, 76 insertions(+), 2 deletions(-) create mode 100644 include/linux/power/isp1704_charger.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] arm: omap2plus: kill section mismatches
Those were very simple to fix and while we should
be putting effort on code consolidation, having
a noisy compilation is very painful and makes it
more difficult to see newer warnings introduced
by re-factoring other code.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c| 10 +-
arch/arm/mach-omap2/board-4430sdp.c|8
arch/arm/mach-omap2/board-omap4panda.c |8
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 9afd087..5f15767 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -719,25 +719,25 @@ static struct omap_device_pad serial3_pads[] __initdata =
{
OMAP_MUX_MODE0),
};
-static struct omap_board_data serial1_data = {
+static struct omap_board_data serial1_data __initdata = {
.id = 0,
.pads = serial1_pads,
.pads_cnt = ARRAY_SIZE(serial1_pads),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static inline void board_serial_init(void)
+static inline void __init board_serial_init(void)
{
omap_serial_init_port(serial1_data);
omap_serial_init_port(serial2_data);
@@ -746,7 +746,7 @@ static inline void board_serial_init(void)
#else
#define board_mux NULL
-static inline void board_serial_init(void)
+static inline void __init board_serial_init(void)
{
omap_serial_init();
}
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56702c5..ab701cd 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -736,25 +736,25 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
};
-static inline void board_serial_init(void)
+static inline void __init board_serial_init(void)
{
struct omap_board_data bdata;
bdata.flags = 0;
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index f3a7b10..4573b96 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -551,25 +551,25 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
};
-static inline void board_serial_init(void)
+static inline void __init board_serial_init(void)
{
struct omap_board_data bdata;
bdata.flags = 0;
--
1.7.4.1.343.ga91df
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] arm: omap2plus: kill section mismatches
On 4/7/2011 1:35 PM, Felipe Balbi wrote: Those were very simple to fix and while we should be putting effort on code consolidation, having a noisy compilation is very painful and makes it more difficult to see newer warnings introduced by re-factoring other code. Signed-off-by: Felipe Balbiba...@ti.com --- I did post one for section mismatch already :) http://www.spinics.net/lists/linux-omap/msg49557.html Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] arm: omap2plus: kill section mismatches
On Thu, Apr 07, 2011 at 01:51:49PM +0530, Santosh Shilimkar wrote: On 4/7/2011 1:35 PM, Felipe Balbi wrote: Those were very simple to fix and while we should be putting effort on code consolidation, having a noisy compilation is very painful and makes it more difficult to see newer warnings introduced by re-factoring other code. Signed-off-by: Felipe Balbiba...@ti.com --- I did post one for section mismatch already :) http://www.spinics.net/lists/linux-omap/msg49557.html oops, let's use that one instead :-) -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi Ming, On Wednesday 06 April 2011 11:37 AM, Ming Lei wrote: Hi Avik, 2011/4/5 Avik Silavik...@linux.vnet.ibm.com: Even after using ioremapped addresses in omap_writel() I'm getting the oops. Can you please point me to the location in mainline, where these l3 clocks are enabled? I guess you can find here: l3_main_3_ick l3_instr_ick: arch/arm/mach-omap2/clock44xx_data.c the clocks are set as ENABLE_ON_INIT. Those clocks are also set ENABLE_ON_INIT in the linaro kernel. But still it's hanging at val = __raw_readl(base + LOCKSTATUS); in cti_unlock(), even after explicitly enabling it using: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL) 0x300) != 0x300); BTW, the oops were fixed by replacing omap_writel with __raw_writel. Regards, Avik thanks, -- 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: What is missing from musb - linux-omap merge?
Hi, -Original Message- From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Wednesday, April 06, 2011 6:54 PM To: OMAP Linux discussion Cc: Felipe Balbi; Hema HK Subject: What is missing from musb - linux-omap merge? Hi I've been trying to hunt why the OMAP3 retention on Nokia N900 went broken in 2.6.39-rc and reason is somewhere around musb code merge with linux-omap code or vise versa. I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board and don't observe any issues. Core is transitioning to retention without any issue, with or without musb driver loaded. But on OMAP3430SDP I am observing the crash when try to do echo mem /sys/power/state. Attached is the fix for this issue and core transitions to retention. When you say retention is not working can you please carify what is happening? are you trying in idle path retention or suspend/resume? Regards, Hema I bisected this into: commit 0df0914d414a504b975f3cc66ace0c16ef55b7f3 Merge: 6899608 05f6894 Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Mar 17 19:28:15 2011 -0700 Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 Yep, there were conflicts resolved by Linus but those didn't look that they explain the problem. So then I went to check the linux-omap branch omap-for-linus that got pulled to vanilla. Top commit was: commit 05f689400ea5fa3d71af82f910c8b140f87ad1f3 Merge: 17fe12c 02b7b94 Author: Tony Lindgren t...@atomide.com Date: Mon Mar 14 11:22:22 2011 -0700 Merge branches 'devel-mux' and 'devel-misc' into omap-for-linus Here retention and usb networking are working so all were fine in linux-omap in 2.6.38-rc7. Then back to vanilla and checking the usb pull. commit 971f115a50afbe409825c9f3399d5a3b9aca4381 Merge: 2e270d8 500132a Author: Linus Torvalds torva...@linux-foundation.org Date: Wed Mar 16 15:04:26 2011 -0700 Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 Yes, musb doesn't compile here... trivial build fix attached as it's not our interest now (but will bother all bisecters). Here retention works but usb networking doesn't. Then I went testing patches from linux-omap/omap-for-linus on top of vanilla commit that precedes the omap-for-linus pull: commit 6899608533410557e6698cb9d4ff6df553916e98 Merge: 411f5c7 92c260f Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Mar 17 19:13:18 2011 -0700 Merge branch 'for-linus' of git://codeaurora.org/quic/kernel/davidb/linux-ms Some amount of conflict resolving, mostly trivial, some testing and came around these commits (note local commit ids): commit 5cd15f0ba7594e4cd1dd01a100dc94013930a6a9 Author: Hema HK hem...@ti.com Date: Thu Feb 17 12:07:17 2011 +0530 OMAP2430: hwmod data: Add USBOTG - Retention ok commit 2d982bb2593ab64151c4a01758735e67d7db5d36 Author: Hema HK hem...@ti.com Date: Thu Feb 17 12:07:18 2011 +0530 OMAP3xxx: hwmod data: Add USBOTG commit 6dc0c8ee8bdaac3ad11c4313431d8d7b3c886ede Author: Hema HK hem...@ti.com Date: Thu Feb 17 12:07:19 2011 +0530 AM35xx: hwmod data: Add USBOTG - These don't boot commit 4bd3924ed10bef872e1fbfbb590fb7132df7dd4c Author: Hema HK hem...@ti.com Date: Thu Feb 17 12:07:21 2011 +0530 OMAP2+: musb: hwmod adaptation for musb registration - Boots, usb networking works and but no retention Then arch/arm/mach-omap2 diff between vanilla 0df0914d414a504b975f3cc66ace0c16ef55b7f3 (l-o pull) and l-o 05f689400ea5fa3d71af82f910c8b140f87ad1f3 (for linus) doesn't show any suspicious to me. E.g. no differences in omap_hwmod_3xxx_data.c and clock3xxx_data.c changes are just those clock name changes that Linus complained. Rest seems to be unrelated. Kconfig|1 Makefile |2 board-3430sdp.c| 10 board-3630sdp.c| 10 board-4430sdp.c|1 board-am3517crane.c| 10 board-am3517evm.c | 12 board-cm-t35.c | 10 board-cm-t3517.c | 10 board-devkit8000.c | 10 board-igep0020.c | 10 board-igep0030.c | 10 board-omap3beagle.c| 10 board-omap3evm.c | 14 - board-omap3pandora.c | 10 board-omap3stalker.c | 10 board-omap3touchbook.c | 10 board-omap4panda.c | 11 board-overo.c | 10 board-zoom.c | 10 clock3xxx_data.c | 19 + clock44xx_data.c | 10 include/mach/board-zoom.h.orig | 11 include/mach/debug-macro.S | 13 omap4-common.c |7 omap_phy_internal.c| 29 +- pm.h |2 sleep24xx.S|2 sleep34xx.S|2 sram242x.S |3 sram243x.S |3 sram34xx.S
omap: USB host disconnects connecting a device through USB HUB
Hi all, I'm experimenting some issues with USB on IGEP v2 board, in certain cases I've an USB disconnect when I plug a device. For me it fails with kernel 2.6.35 but I think it also affect newer kernel, the issue is easy to reproduce following these steps: 1. Power up the board (without any device connected ) 2. When kernel is up, connect a powered USB HUB 2.0 to the USB host port, kernel shows, usb 1-1: new high speed USB device using ehci-omap and address 2 usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.4: new high speed USB device using ehci-omap and address 3 usb 1-1.4: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1.4: Product: USB2.0 Hub hub 1-1.4:1.0: USB hub found hub 1-1.4:1.0: 4 ports detected 3. Then if I connect a device (for example a pendrive) to the HUB I get USB disconnect message usb 1-1: USB disconnect, address 2 usb 1-1.4: USB disconnect, address 3 OTOH, it works without problem 1. if power up the board with the USB HUB connected to the USB Host port and the device connected to the USB hub. 2. if after kernel is up, connect the USB HUB + device to the USB Host port Anyone is experimenting something like this with other OMAP3-based boards ? Regards, Enric Balletbò i Serra -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi Avik, Please check if the option CONFIG_PM is enabled or not. If not, please try to enable it to see you issue can be fixed. 2011/4/7 Avik Sil avik...@linux.vnet.ibm.com: Hi Ming, On Wednesday 06 April 2011 11:37 AM, Ming Lei wrote: Hi Avik, 2011/4/5 Avik Silavik...@linux.vnet.ibm.com: Even after using ioremapped addresses in omap_writel() I'm getting the oops. Can you please point me to the location in mainline, where these l3 clocks are enabled? I guess you can find here: l3_main_3_ick l3_instr_ick: arch/arm/mach-omap2/clock44xx_data.c the clocks are set as ENABLE_ON_INIT. Those clocks are also set ENABLE_ON_INIT in the linaro kernel. But still it's hanging at val = __raw_readl(base + LOCKSTATUS); in cti_unlock(), even after explicitly enabling it using: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL) 0x300) != 0x300); BTW, the oops were fixed by replacing omap_writel with __raw_writel. Regards, Avik thanks, thanks, -- Ming Lei -- 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: TI816X: Add SATA support
From: Mansoor Ahamed mansoor.aha...@ti.com
Add support for SATA controller on the
TI816X devices.
TI816X supports 1 HBA with 2 ports (dedicated DMA).
This is a Gen 2 HBA with 3Gbps support.
It supports Port Multiplier but only in
Command Based Switching mode.
The patch adds required platform resource and
SATA controller initialization routine.
The PHY configuration in this patch is
courtesy of the work done by Zegeye Alemu and
Swaminathan from TI.
While testing this patch, enable port multiplier
support if you are actually using one.
Reason for this behaviour is discussed
here: http://patchwork.ozlabs.org/patch/78163/
Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com
---
This patch depends on patch TI816X: clock: Add clock data
from Hemant Pedanekar hema...@ti.com
arch/arm/mach-omap2/devices.c | 126 +
1 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d478f53..9c33022 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -16,6 +16,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/slab.h
+#include linux/ahci_platform.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include mach/irqs.h
@@ -100,6 +102,129 @@ static int __init omap4_l3_init(void)
}
postcore_initcall(omap4_l3_init);
+#if defined(CONFIG_SATA_AHCI_PLATFORM) || \
+ defined(CONFIG_SATA_AHCI_PLATFORM_MODULE)
+
+static struct ahci_platform_data omap_sata_pdata;
+static u64 omap_sata_dmamask = DMA_BIT_MASK(32);
+static struct clk *omap_sata_clk;
+
+/* SATA PHY control register offsets */
+#define SATA_P0PHYCR_REG 0x178
+#define SATA_P1PHYCR_REG 0x1F8
+
+#define SATA_PHY_ENPLL(x) ((x) 0)
+#define SATA_PHY_MPY(x)((x) 1)
+#define SATA_PHY_LB(x) ((x) 5)
+#define SATA_PHY_CLKBYP(x) ((x) 7)
+#define SATA_PHY_RXINVPAIR(x) ((x) 9)
+#define SATA_PHY_LBK(x)((x) 10)
+#define SATA_PHY_RXLOS(x) ((x) 12)
+#define SATA_PHY_RXCDR(x) ((x) 13)
+#define SATA_PHY_RXEQ(x) ((x) 16)
+#define SATA_PHY_RXENOC(x) ((x) 20)
+#define SATA_PHY_TXINVPAIR(x) ((x) 21)
+#define SATA_PHY_TXCM(x) ((x) 22)
+#define SATA_PHY_TXSWING(x)((x) 23)
+#define SATA_PHY_TXDE(x) ((x) 27)
+
+#define TI816X_SATA_BASE 0x4A14
+
+static int ti816x_ahci_plat_init(struct device *dev, void __iomem *base)
+{
+ unsigned int phy_val;
+ int ret;
+
+ omap_sata_clk = clk_get(dev, NULL);
+ if (IS_ERR(omap_sata_clk)) {
+ pr_err(ahci : Failed to get SATA clock\n);
+ return PTR_ERR(omap_sata_clk);
+ }
+
+ if (!base) {
+ pr_err(ahci : SATA reg space not mapped, PHY enable failed\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = clk_enable(omap_sata_clk);
+ if (ret) {
+ pr_err(ahci : Clock enable failed\n);
+ goto err;
+ }
+
+ phy_val = SATA_PHY_ENPLL(1) |
+ SATA_PHY_MPY(8) |
+ SATA_PHY_LB(0) |
+ SATA_PHY_CLKBYP(0) |
+ SATA_PHY_RXINVPAIR(0) |
+ SATA_PHY_LBK(0) |
+ SATA_PHY_RXLOS(1) |
+ SATA_PHY_RXCDR(4) |
+ SATA_PHY_RXEQ(1) |
+ SATA_PHY_RXENOC(1) |
+ SATA_PHY_TXINVPAIR(0) |
+ SATA_PHY_TXCM(0) |
+ SATA_PHY_TXSWING(7) |
+ SATA_PHY_TXDE(0);
+
+ writel(phy_val, base + SATA_P0PHYCR_REG);
+ writel(phy_val, base + SATA_P1PHYCR_REG);
+
+ return 0;
+err:
+ clk_put(omap_sata_clk);
+ return ret;
+}
+
+static void ti816x_ahci_plat_exit(struct device *dev)
+{
+ clk_disable(omap_sata_clk);
+ clk_put(omap_sata_clk);
+}
+
+/* resources will be filled by soc specific init routine */
+static struct resource omap_ahci_resources[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device omap_ahci_device = {
+ .name = ahci,
+ .dev= {
+ .platform_data = omap_sata_pdata,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .dma_mask = omap_sata_dmamask,
+ },
+ .num_resources = ARRAY_SIZE(omap_ahci_resources),
+ .resource = omap_ahci_resources,
+};
+
+static void ti816x_ahci_init(void)
+{
+ /* fixup platform device info for TI816X */
+ omap_ahci_resources[0].start= TI816X_SATA_BASE;
+ omap_ahci_resources[0].end = TI816X_SATA_BASE + 0x10fff;
+ omap_ahci_resources[1].start= 16; /* SATA IRQ */
+ omap_sata_pdata.init= ti816x_ahci_plat_init;
+ omap_sata_pdata.exit=
Re: What is missing from musb - linux-omap merge?
Hi On Thu, 7 Apr 2011 14:38:06 +0530 Hema Kalliguddi hem...@ti.com wrote: I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board and don't observe any issues. Core is transitioning to retention without any issue, with or without musb driver loaded. But on OMAP3430SDP I am observing the crash when try to do echo mem /sys/power/state. Attached is the fix for this issue and core transitions to retention. Hmm.. suspend/resume are fine on Nokia N900 with and without the patch. Patch also didn't fix the idle retention. When you say retention is not working can you please carify what is happening? are you trying in idle path retention or suspend/resume? Sorry not being verbose enough, I was testing the idle retention. For me it looks these differencies are explained by different bootloaders. As Kevin told they may leave MUSB in a wrong state. Was it so that before hwmod conversion the musb did IP reset etc and now this feature is missing? So I'm thinking is this problem a regression or missing feature after hwmod conversion? -- 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
Re: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi Ming, On Thursday 07 April 2011 03:24 PM, Ming Lei wrote: Hi Avik, Please check if the option CONFIG_PM is enabled or not. CONFIG_PM is enabled in my config: $ grep CONFIG_PM .config CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_PM_RUNTIME=y CONFIG_PM_OPS=y CONFIG_PM_OPP=y CONFIG_PMIC_DA903X=y CONFIG_PMIC_ADP5520=y As suggested in http://groups.google.com/group/pandaboard/browse_thread/thread/74abf5dafa2fd6e2/b1cc29b5060b4223?#b1cc29b5060b4223 , do you think prcm_setup_regs() has to be called for OMAP4? Regards, Avik If not, please try to enable it to see you issue can be fixed. 2011/4/7 Avik Silavik...@linux.vnet.ibm.com: Hi Ming, On Wednesday 06 April 2011 11:37 AM, Ming Lei wrote: Hi Avik, 2011/4/5 Avik Silavik...@linux.vnet.ibm.com: Even after using ioremapped addresses in omap_writel() I'm getting the oops. Can you please point me to the location in mainline, where these l3 clocks are enabled? I guess you can find here: l3_main_3_ickl3_instr_ick: arch/arm/mach-omap2/clock44xx_data.c the clocks are set as ENABLE_ON_INIT. Those clocks are also set ENABLE_ON_INIT in the linaro kernel. But still it's hanging at val = __raw_readl(base + LOCKSTATUS); in cti_unlock(), even after explicitly enabling it using: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL) 0x300) != 0x300); BTW, the oops were fixed by replacing omap_writel with __raw_writel. Regards, Avik thanks, thanks, -- 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: TI816X: Add SATA support
Hi,
On Thu, Apr 07, 2011 at 03:54:47PM +0530, Basheer, Mansoor Ahamed wrote:
@@ -100,6 +102,129 @@ static int __init omap4_l3_init(void)
}
postcore_initcall(omap4_l3_init);
+#if defined(CONFIG_SATA_AHCI_PLATFORM) || \
+ defined(CONFIG_SATA_AHCI_PLATFORM_MODULE)
+
+static struct ahci_platform_data omap_sata_pdata;
+static u64 omap_sata_dmamask = DMA_BIT_MASK(32);
+static struct clk *omap_sata_clk;
+
+/* SATA PHY control register offsets */
+#define SATA_P0PHYCR_REG 0x178
+#define SATA_P1PHYCR_REG 0x1F8
prepend all with TI816X_
+#define SATA_PHY_ENPLL(x)((x) 0)
+#define SATA_PHY_MPY(x) ((x) 1)
+#define SATA_PHY_LB(x) ((x) 5)
+#define SATA_PHY_CLKBYP(x) ((x) 7)
+#define SATA_PHY_RXINVPAIR(x)((x) 9)
+#define SATA_PHY_LBK(x) ((x) 10)
+#define SATA_PHY_RXLOS(x)((x) 12)
+#define SATA_PHY_RXCDR(x)((x) 13)
+#define SATA_PHY_RXEQ(x) ((x) 16)
+#define SATA_PHY_RXENOC(x) ((x) 20)
+#define SATA_PHY_TXINVPAIR(x)((x) 21)
+#define SATA_PHY_TXCM(x) ((x) 22)
+#define SATA_PHY_TXSWING(x) ((x) 23)
the ones which are single bits, you define as:
#define TI816X_SATA_PHY_TXINVPAIR (1 21)
or
#define TI816X_SATA_PHY_TXINVPAIR BIT(21)
+#define SATA_PHY_TXDE(x) ((x) 27)
+
+#define TI816X_SATA_BASE 0x4A14
you should probably define these on some header file. Also SATA_BASE
should be an increment to the global base.
+
+static int ti816x_ahci_plat_init(struct device *dev, void __iomem *base)
+{
+ unsigned int phy_val;
+ int ret;
+
+ omap_sata_clk = clk_get(dev, NULL);
+ if (IS_ERR(omap_sata_clk)) {
+ pr_err(ahci : Failed to get SATA clock\n);
+ return PTR_ERR(omap_sata_clk);
+ }
can't you use pm_runtime do achieve this ?
+
+ if (!base) {
+ pr_err(ahci : SATA reg space not mapped, PHY enable failed\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = clk_enable(omap_sata_clk);
+ if (ret) {
+ pr_err(ahci : Clock enable failed\n);
+ goto err;
+ }
+
+ phy_val = SATA_PHY_ENPLL(1) |
+ SATA_PHY_MPY(8) |
+ SATA_PHY_LB(0) |
+ SATA_PHY_CLKBYP(0) |
+ SATA_PHY_RXINVPAIR(0) |
+ SATA_PHY_LBK(0) |
+ SATA_PHY_RXLOS(1) |
+ SATA_PHY_RXCDR(4) |
+ SATA_PHY_RXEQ(1) |
+ SATA_PHY_RXENOC(1) |
+ SATA_PHY_TXINVPAIR(0) |
+ SATA_PHY_TXCM(0) |
+ SATA_PHY_TXSWING(7) |
+ SATA_PHY_TXDE(0);
if it's 0, it's same as not even adding them. Please remove the ones
which are 0.
+ writel(phy_val, base + SATA_P0PHYCR_REG);
+ writel(phy_val, base + SATA_P1PHYCR_REG);
+
+ return 0;
+err:
+ clk_put(omap_sata_clk);
+ return ret;
+}
+
+static void ti816x_ahci_plat_exit(struct device *dev)
+{
+ clk_disable(omap_sata_clk);
+ clk_put(omap_sata_clk);
+}
+
+/* resources will be filled by soc specific init routine */
+static struct resource omap_ahci_resources[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device omap_ahci_device = {
+ .name = ahci,
+ .dev= {
+ .platform_data = omap_sata_pdata,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .dma_mask = omap_sata_dmamask,
+ },
+ .num_resources = ARRAY_SIZE(omap_ahci_resources),
+ .resource = omap_ahci_resources,
+};
+
+static void ti816x_ahci_init(void)
+{
+ /* fixup platform device info for TI816X */
+ omap_ahci_resources[0].start= TI816X_SATA_BASE;
+ omap_ahci_resources[0].end = TI816X_SATA_BASE + 0x10fff;
weird resource size... 68k... Ok, anyway.. as long as it's correct :-p
+ omap_ahci_resources[1].start= 16; /* SATA IRQ */
+ omap_sata_pdata.init= ti816x_ahci_plat_init;
+ omap_sata_pdata.exit= ti816x_ahci_plat_exit;
why didn't you initialize these when defining the resources ?
you could even drop this function altogether.
+}
+
+static inline void omap_init_ahci(void)
+{
+ if (cpu_is_ti816x()) {
+ ti816x_ahci_init();
+ platform_device_register(omap_ahci_device);
+ }
this is better the other way around:
if (!cpu_is_ti816x())
return;
platform_device_register(omap_ahci_device);
--
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: What is missing from musb - linux-omap merge?
On Thu, Apr 07, 2011 at 01:34:52PM +0300, Jarkko Nikula wrote: Hi On Thu, 7 Apr 2011 14:38:06 +0530 Hema Kalliguddi hem...@ti.com wrote: I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board and don't observe any issues. Core is transitioning to retention without any issue, with or without musb driver loaded. But on OMAP3430SDP I am observing the crash when try to do echo mem /sys/power/state. Attached is the fix for this issue and core transitions to retention. Hmm.. suspend/resume are fine on Nokia N900 with and without the patch. Patch also didn't fix the idle retention. When you say retention is not working can you please carify what is happening? are you trying in idle path retention or suspend/resume? Sorry not being verbose enough, I was testing the idle retention. For me it looks these differencies are explained by different bootloaders. As Kevin told they may leave MUSB in a wrong state. Was it so that before hwmod conversion the musb did IP reset etc and now this feature is missing? So I'm thinking is this problem a regression or missing feature after hwmod conversion? it's possibly a regression. I remember we had softreset before. Should be fixed. -- 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: What is missing from musb - linux-omap merge?
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Thursday, April 07, 2011 5:08 PM To: Jarkko Nikula Cc: Hema Kalliguddi; OMAP Linux discussion; Felipe Balbi Subject: Re: What is missing from musb - linux-omap merge? On Thu, Apr 07, 2011 at 01:34:52PM +0300, Jarkko Nikula wrote: Hi On Thu, 7 Apr 2011 14:38:06 +0530 Hema Kalliguddi hem...@ti.com wrote: I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board and don't observe any issues. Core is transitioning to retention without any issue, with or without musb driver loaded. But on OMAP3430SDP I am observing the crash when try to do echo mem /sys/power/state. Attached is the fix for this issue and core transitions to retention. Hmm.. suspend/resume are fine on Nokia N900 with and without the patch. Patch also didn't fix the idle retention. When you say retention is not working can you please carify what is happening? are you trying in idle path retention or suspend/resume? Sorry not being verbose enough, I was testing the idle retention. For me it looks these differencies are explained by different bootloaders. As Kevin told they may leave MUSB in a wrong state. Was it so that before hwmod conversion the musb did IP reset etc and now this feature is missing? So I'm thinking is this problem a regression or missing feature after hwmod conversion? Hwmod will take care of restting the ip if the SYSC_HAS_SOFTRESET sysc_flag is set. And it is being set in the hwmod structure of OMAP3. I tested both idle path and suspend/resume retention and works fine on OMAP3430SDP. I am wondering what might be the problem with N900. Is it works if you do the ip reset in the musb driver? Regards, Hema it's possibly a regression. I remember we had softreset before. Should be fixed. -- 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: What is missing from musb - linux-omap merge?
Hi, -Original Message- From: Hema Kalliguddi [mailto:hem...@ti.com] Sent: Thursday, April 07, 2011 6:29 PM To: ba...@ti.com; Jarkko Nikula Cc: OMAP Linux discussion Subject: RE: What is missing from musb - linux-omap merge? -Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Thursday, April 07, 2011 5:08 PM To: Jarkko Nikula Cc: Hema Kalliguddi; OMAP Linux discussion; Felipe Balbi Subject: Re: What is missing from musb - linux-omap merge? On Thu, Apr 07, 2011 at 01:34:52PM +0300, Jarkko Nikula wrote: Hi On Thu, 7 Apr 2011 14:38:06 +0530 Hema Kalliguddi hem...@ti.com wrote: I tried the core retention with v2.6.39-rc1 with OMAP3630Zoom3 board and don't observe any issues. Core is transitioning to retention without any issue, with or without musb driver loaded. But on OMAP3430SDP I am observing the crash when try to do echo mem /sys/power/state. Attached is the fix for this issue and core transitions to retention. Hmm.. suspend/resume are fine on Nokia N900 with and without the patch. Patch also didn't fix the idle retention. When you say retention is not working can you please carify what is happening? are you trying in idle path retention or suspend/resume? Sorry not being verbose enough, I was testing the idle retention. For me it looks these differencies are explained by different bootloaders. As Kevin told they may leave MUSB in a wrong state. Was it so that before hwmod conversion the musb did IP reset etc and now this feature is missing? So I'm thinking is this problem a regression or missing feature after hwmod conversion? Hwmod will take care of restting the ip if the SYSC_HAS_SOFTRESET sysc_flag is set. And it is being set in the hwmod structure of OMAP3. I tested both idle path and suspend/resume retention and works fine on OMAP3430SDP. Tested with OMAP3630Zoom3 board not with 3430SDP. I am wondering what might be the problem with N900. Is it works if you do the ip reset in the musb driver? Regards, Hema it's possibly a regression. I remember we had softreset before. Should be fixed. -- 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: omap: USB host disconnects connecting a device through USB HUB
On Thu, 7 Apr 2011, Enric Balletbò i Serra wrote: Hi all, I'm experimenting some issues with USB on IGEP v2 board, in certain cases I've an USB disconnect when I plug a device. For me it fails with kernel 2.6.35 but I think it also affect newer kernel, the issue is easy to reproduce following these steps: 1. Power up the board (without any device connected ) 2. When kernel is up, connect a powered USB HUB 2.0 to the USB host port, kernel shows, usb 1-1: new high speed USB device using ehci-omap and address 2 usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.4: new high speed USB device using ehci-omap and address 3 usb 1-1.4: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1.4: Product: USB2.0 Hub hub 1-1.4:1.0: USB hub found hub 1-1.4:1.0: 4 ports detected 3. Then if I connect a device (for example a pendrive) to the HUB I get USB disconnect message usb 1-1: USB disconnect, address 2 usb 1-1.4: USB disconnect, address 3 OTOH, it works without problem 1. if power up the board with the USB HUB connected to the USB Host port and the device connected to the USB hub. 2. if after kernel is up, connect the USB HUB + device to the USB Host port Anyone is experimenting something like this with other OMAP3-based boards ? At first glance, it looks like a power-related issue. Current inrush when the device is plugged in, or something like that. What happens if you attach the hub and pendrive to a standard PC? 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: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
[adding linux-pm, which I forgot to add in original post] Rafael J. Wysocki r...@suse.com writes: On Thursday, April 07, 2011, Kevin Hilman wrote: This series aims to consolidate OMAP and SH-mobile runtime PM implementations around the new device power domains. In 2.6.39, device power domains were added (commit 7538e3db6e015e890825fbd9f8659952896ddd5b, PM: add support for device power domains). In converting both OMAP and SH-mobile to use device power domains, the overlap between implementations was almost 100%. To share the runtime PM implementation based on simple clock gating, move it to arch/arm/common and initialize it from OMAP and SH-mobile. Also, OMAP was the only user of platform_bus_set_pm_ops(). Now that it has been converted to device power domains, remove platform_bus_set_pm_ops(). Please, don't do it this way. First, we'll still need platform_bus_set_pm_ops() on shmobile and the reason is that we want to override the platform bus type PM ops for _all_ devices on that platform, which power domains are not really suitable for. That doesn't sound quite right to me. Magnus should step in here to clarify the situation on SH-mobile, but like Grant, I'm pretty sure that we don't need (or want) to replace PM ops for _all_ platform devices. Looking at the replacement ops used, they simply manage device clocks, and this probably only applies to on-chip devices (at least that's true on OMAP.) Replacing the PM ops for all devices was done on OMAP and SH-mobile because that was the only approach we had. Now that we have device power domains (thanks Rafael!), we can be more selective about which devices to apply them to. Note that my RFC patch/series did not do the selective part of deciding which devices to override and which ones not to, that part will be platform specific. Second, we're going to introduce code for handling real power domains for shmobile that would conflict with the way you're using power domains for overriding the default PM ops. Conflict in what way? If you have new device power domain callbacks for specific devices in a an on-chp power domain, they would just override the default ones that only do basic clock gating. I'm guessing the new callbacks will do some management of the SoC specific powerdomains in addition to clock gating. That's how it works on OMAP. Put a different way, the device power domain callbacks in this proposal will be the defaults, providing a simple clock-gating only approach to device power management. However, when new code comes along to manage the actual SoC power domains, devices in those power domains will just override these default clock-gating-only versions. This is exactly how things are working in OMAP. On OMAP1, we use only the simple, clock-gating only callbacks because the OMAP1 PM capabilities are much more limited. On OMAP2+, we override these callbacks with different ones that in addition to managing clocks, also manage the SoC power domains. Besides, the way you've used power domains appears to assume that drivers will not define their own runtime PM callbacks, because if they do, those callbacks will be called _in_ _addition_ to the power domain callbacks you're trying to add (from the default platform bus type callbacks). That was intentional. If all a driver needs to do for runtime PM is manage clocks, it doesn't need runtime PM callbacks since it's hanlded by core code. If it has additional things to do (save context, quiesce hardware, wait for somthing to finish etc.) it can do that in it's own callbacks, and then the clock gating will happen in the device power domain callbacks. The point is use both levels of callbacks. The device power domain callbacks handle all the operations that are common to the device power domain, and the driver callbacks handle driver specific stuff. It also means that drivers don't have to manage their own clocks, at least for PM purposes. This is a big win for drivers that are used on multiple platforms, or even multiple SoCs in the same family where clocking may be different. Drivers that can remain ignorant of the underlying clocking (and power domain layout) are much more portable. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: TI816X: Add SATA support
On 4/7/2011 1:23 PM, Balbi, Felipe wrote:
Hi,
On Thu, Apr 07, 2011 at 03:54:47PM +0530, Basheer, Mansoor Ahamed wrote:
@@ -100,6 +102,129 @@ static int __init omap4_l3_init(void)
}
postcore_initcall(omap4_l3_init);
+#if defined(CONFIG_SATA_AHCI_PLATFORM) || \
+ defined(CONFIG_SATA_AHCI_PLATFORM_MODULE)
+
+static struct ahci_platform_data omap_sata_pdata;
+static u64 omap_sata_dmamask = DMA_BIT_MASK(32);
+static struct clk *omap_sata_clk;
+
+/* SATA PHY control register offsets */
+#define SATA_P0PHYCR_REG 0x178
+#define SATA_P1PHYCR_REG 0x1F8
prepend all with TI816X_
+#define SATA_PHY_ENPLL(x) ((x) 0)
+#define SATA_PHY_MPY(x)((x) 1)
+#define SATA_PHY_LB(x) ((x) 5)
+#define SATA_PHY_CLKBYP(x) ((x) 7)
+#define SATA_PHY_RXINVPAIR(x) ((x) 9)
+#define SATA_PHY_LBK(x)((x) 10)
+#define SATA_PHY_RXLOS(x) ((x) 12)
+#define SATA_PHY_RXCDR(x) ((x) 13)
+#define SATA_PHY_RXEQ(x) ((x) 16)
+#define SATA_PHY_RXENOC(x) ((x) 20)
+#define SATA_PHY_TXINVPAIR(x) ((x) 21)
+#define SATA_PHY_TXCM(x) ((x) 22)
+#define SATA_PHY_TXSWING(x)((x) 23)
the ones which are single bits, you define as:
#define TI816X_SATA_PHY_TXINVPAIR (1 21)
or
#define TI816X_SATA_PHY_TXINVPAIR BIT(21)
+#define SATA_PHY_TXDE(x) ((x) 27)
+
+#define TI816X_SATA_BASE 0x4A14
you should probably define these on some header file. Also SATA_BASE
should be an increment to the global base.
In fact, you should even use hwmod data for that.
+
+static int ti816x_ahci_plat_init(struct device *dev, void __iomem *base)
+{
+ unsigned int phy_val;
+ int ret;
+
+ omap_sata_clk = clk_get(dev, NULL);
+ if (IS_ERR(omap_sata_clk)) {
+ pr_err(ahci : Failed to get SATA clock\n);
+ return PTR_ERR(omap_sata_clk);
+ }
can't you use pm_runtime do achieve this ?
+
+ if (!base) {
+ pr_err(ahci : SATA reg space not mapped, PHY enable failed\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = clk_enable(omap_sata_clk);
+ if (ret) {
+ pr_err(ahci : Clock enable failed\n);
+ goto err;
+ }
As Felipe suggested, pm_runtime is probably the right API for that.
It should even potentially be done in the driver directly since it is a
generic API and most platform should probably have to enable something
at that time.
Benoit
+
+ phy_val = SATA_PHY_ENPLL(1) |
+ SATA_PHY_MPY(8) |
+ SATA_PHY_LB(0) |
+ SATA_PHY_CLKBYP(0) |
+ SATA_PHY_RXINVPAIR(0) |
+ SATA_PHY_LBK(0) |
+ SATA_PHY_RXLOS(1) |
+ SATA_PHY_RXCDR(4) |
+ SATA_PHY_RXEQ(1) |
+ SATA_PHY_RXENOC(1) |
+ SATA_PHY_TXINVPAIR(0) |
+ SATA_PHY_TXCM(0) |
+ SATA_PHY_TXSWING(7) |
+ SATA_PHY_TXDE(0);
if it's 0, it's same as not even adding them. Please remove the ones
which are 0.
+ writel(phy_val, base + SATA_P0PHYCR_REG);
+ writel(phy_val, base + SATA_P1PHYCR_REG);
+
+ return 0;
+err:
+ clk_put(omap_sata_clk);
+ return ret;
+}
+
+static void ti816x_ahci_plat_exit(struct device *dev)
+{
+ clk_disable(omap_sata_clk);
+ clk_put(omap_sata_clk);
+}
+
+/* resources will be filled by soc specific init routine */
+static struct resource omap_ahci_resources[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
+static struct platform_device omap_ahci_device = {
+ .name = ahci,
+ .dev= {
+ .platform_data =omap_sata_pdata,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .dma_mask =omap_sata_dmamask,
+ },
+ .num_resources = ARRAY_SIZE(omap_ahci_resources),
+ .resource = omap_ahci_resources,
+};
+
+static void ti816x_ahci_init(void)
+{
+ /* fixup platform device info for TI816X */
+ omap_ahci_resources[0].start= TI816X_SATA_BASE;
+ omap_ahci_resources[0].end = TI816X_SATA_BASE + 0x10fff;
weird resource size... 68k... Ok, anyway.. as long as it's correct :-p
+ omap_ahci_resources[1].start= 16; /* SATA IRQ */
+ omap_sata_pdata.init= ti816x_ahci_plat_init;
+ omap_sata_pdata.exit= ti816x_ahci_plat_exit;
why didn't you initialize these when defining the resources ?
you could even drop this function altogether.
+}
+
+static inline void omap_init_ahci(void)
+{
+ if (cpu_is_ti816x()) {
+ ti816x_ahci_init();
+ platform_device_register(omap_ahci_device);
+ }
this is better the other way around:
if
Re: [PATCH/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms
On Wed, Apr 06, 2011 at 05:02:47PM -0700, Kevin Hilman wrote: There is really nothing SH-mobile specific about this runtime PM implementation. Any platform wanting to implement runtime PM based on simple clock gating can use this implementation. Signed-off-by: Kevin Hilman khil...@ti.com This observation is wholly architecture agnostic, so it's not clear that keeping it in arch/arm/common is any better. It seems that this would be better suited for drivers/base/power/ with a generic Kconfig symbol. -- 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/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms
Paul Mundt let...@linux-sh.org writes: On Wed, Apr 06, 2011 at 05:02:47PM -0700, Kevin Hilman wrote: There is really nothing SH-mobile specific about this runtime PM implementation. Any platform wanting to implement runtime PM based on simple clock gating can use this implementation. Signed-off-by: Kevin Hilman khil...@ti.com This observation is wholly architecture agnostic, so it's not clear that keeping it in arch/arm/common is any better. It seems that this would be better suited for drivers/base/power/ with a generic Kconfig symbol. Sounds fine to me. Thanks for the review, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: TI816X: Add SATA support
Cousson, Benoit b-cous...@ti.com writes:
On 4/7/2011 1:23 PM, Balbi, Felipe wrote:
Hi,
On Thu, Apr 07, 2011 at 03:54:47PM +0530, Basheer, Mansoor Ahamed wrote:
@@ -100,6 +102,129 @@ static int __init omap4_l3_init(void)
}
postcore_initcall(omap4_l3_init);
+#if defined(CONFIG_SATA_AHCI_PLATFORM) || \
+ defined(CONFIG_SATA_AHCI_PLATFORM_MODULE)
+
+static struct ahci_platform_data omap_sata_pdata;
+static u64 omap_sata_dmamask = DMA_BIT_MASK(32);
+static struct clk *omap_sata_clk;
+
+/* SATA PHY control register offsets */
+#define SATA_P0PHYCR_REG 0x178
+#define SATA_P1PHYCR_REG 0x1F8
prepend all with TI816X_
+#define SATA_PHY_ENPLL(x) ((x) 0)
+#define SATA_PHY_MPY(x)((x) 1)
+#define SATA_PHY_LB(x) ((x) 5)
+#define SATA_PHY_CLKBYP(x) ((x) 7)
+#define SATA_PHY_RXINVPAIR(x) ((x) 9)
+#define SATA_PHY_LBK(x)((x) 10)
+#define SATA_PHY_RXLOS(x) ((x) 12)
+#define SATA_PHY_RXCDR(x) ((x) 13)
+#define SATA_PHY_RXEQ(x) ((x) 16)
+#define SATA_PHY_RXENOC(x) ((x) 20)
+#define SATA_PHY_TXINVPAIR(x) ((x) 21)
+#define SATA_PHY_TXCM(x) ((x) 22)
+#define SATA_PHY_TXSWING(x)((x) 23)
the ones which are single bits, you define as:
#define TI816X_SATA_PHY_TXINVPAIR(1 21)
or
#define TI816X_SATA_PHY_TXINVPAIRBIT(21)
+#define SATA_PHY_TXDE(x) ((x) 27)
+
+#define TI816X_SATA_BASE 0x4A14
you should probably define these on some header file. Also SATA_BASE
should be an increment to the global base.
In fact, you should even use hwmod data for that.
+
+static int ti816x_ahci_plat_init(struct device *dev, void __iomem *base)
+{
+ unsigned int phy_val;
+ int ret;
+
+ omap_sata_clk = clk_get(dev, NULL);
+ if (IS_ERR(omap_sata_clk)) {
+ pr_err(ahci : Failed to get SATA clock\n);
+ return PTR_ERR(omap_sata_clk);
+ }
can't you use pm_runtime do achieve this ?
+
+ if (!base) {
+ pr_err(ahci : SATA reg space not mapped, PHY enable failed\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = clk_enable(omap_sata_clk);
+ if (ret) {
+ pr_err(ahci : Clock enable failed\n);
+ goto err;
+ }
As Felipe suggested, pm_runtime is probably the right API for that.
It should even potentially be done in the driver directly since it is
a generic API and most platform should probably have to enable
something at that time.
Just to second what Felipe and Benoit already said:
Much of what this patch does duplicates what would happen
automatcially if this was done using omap_hwmod/omap_device + runtime
PM. For example, platform_device creation is automatic with hwmod data
+ omap_device build, and clock management is done by runtime PM.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
Kevin Hilman khil...@ti.com writes: [...] Replacing the PM ops for all devices was done on OMAP and SH-mobile because that was the only approach we had. Now that we have device power domains (thanks Rafael!), we can be more selective about which devices to apply them to. Note that my RFC patch/series did not do the selective part of deciding which devices to override and which ones not to, that part will be platform specific. Actually, thinking about this a little more, my patch actually does select only relevant devices, and not *all* platform devices. In my patch, the device power domain pointers are only added for devices where a clk_get() actually succeeds. In the original version, the runtime PM hooks are overridden for *all* platform devices, but ones that have no clock (or where clk_get() failed) have the additional overhead of still calling the custom PM ops, but the custom ops have nothing to do. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] nohz: delay going tickless under CPU load to favor deeper C states
From: Nicole Chalhoub n-chalh...@ti.com
While there is CPU load, continue the periodic tick in order to give
CPUidle another opportunity to pick a deeper C-state instead of
spending potentially long idle times in a shallow C-state.
Long winded version:
When going idle with a high load average, CPUidle menu governor will
decide to pick a shallow C-state since one of the guiding principles
of the menu governor is The busier the system, the less impact of C
states is acceptable (taken from cpuidle/governors/menu.c.) That
makes perfect sense.
However, there are missed power-saving opportunities for bursty
workloads with long idle times (e.g. MP3 playback.) Given such a
workload, because of the load average, CPUidle tends to pick a shallow
C-state. Because we also go tickless, this shallow C-state is used
for the duration of the idle period. If the idle period is long, a
deeper C state would've resulted in better power savings.
This patch delays going tickless when there is a load such that on the
next tick, the CPUidle governor will have another opportunity to to
pick a deeper C-state. Since the system will have been idle for
potentially a full tick, the load average will drop and a deeper C
state will most likely be chosen.
Delaying NOHZ decisions until the load is zero improved the load
estimation on our ARM/OMAP4 platform where HZ=128 and increased the
time spent in deep C-states (~50% of idle time in C-states deeper than
C1). A power saving of ~20mA at battery level is observed during MP3
playback on OMAP4/Blaze board.
Signed-off-by: Nicole Chalhoub n-chalh...@ti.com
Signed-off-by: Vincent Bour v-b...@ti.com
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Thomas Gleixner t...@linutronix.de
[khil...@ti.com: rework changelog]
Signed-off-by: Kevin Hilman khil...@ti.com
---
kernel/time/tick-sched.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index d5097c4..418066c 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -324,7 +324,7 @@ void tick_nohz_stop_sched_tick(int inidle)
} while (read_seqretry(xtime_lock, seq));
if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) ||
- arch_needs_cpu(cpu)) {
+ arch_needs_cpu(cpu) || this_cpu_load()) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
} else {
--
1.7.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: OMAP4 DSS clock setup
Hello Tomi, Benoît, On Mon, 4 Apr 2011, Tomi Valkeinen wrote: On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote: Based on the E-mail thread so far, I'd say that changing the clock aliases is the way to go for right now. The clock aliases are not hardware data; they just control how the clock hardware is mapped to the drivers. I'd very much prefer this option. Below is a patch for this. If Benoit doesn't complain too much about this, I'd like to get this merged as soon as possible, as OMAP4 DSS is currently crashing in the mainline kernel. I will queue your clock aliases patch and attempt to merge it upstream for the -rc series. I am not happy to be disagreeing with Benoît here, but this is the rationale that I am using. (Benoît, Tomi, please feel free to correct if there is something blatantly false below.) 1. The integration of the DSS module is an unusual case. The MODULEMODE bits for the DSS bits do not control the DSS main functional clock (the clock that is needed to access device registers); instead, they only control the DSS interface clock. (This is because the DSS can use a functional clock that is not provided by the OMAP core.) So calling the DSS MODULEMODE struct clk dss_fck is not really correct, since it is really controlling the interface clock. 2. This patch does not create a precedent for hacking around general driver clocking problems in the clock or clock data. This is only needed because the MODULEMODE bits don't control the module functional clock in this case. As I understand it, the only other device that this problem could occur with is McBSP, due to mcbsp_clks. 3. The existing DSS2 driver clock design apparently works fine when this change is implemented[1], so no driver changes will be needed. 4. The proposed DSS driver patch to work around this uses a nasty hack that really should be NACK'ed[2]. All this said, we may not be able to merge this change upstream, due to the recent unhappiness about the clock data changes. If Linus rejects it, you'll need a Plan B. ... Also, I hope you and the other DSS hackers can finish the PM runtime conversion of the DSS driver soon. Ideally before any new DSS features are added. We really need to be able to separate the OMAP integration details from the drivers, and right now, hwmod and PM runtime are the best way we have to do that. Comments welcome. - Paul 1. Valkeinen, Tomi. _Re: OMAP4 DSS clock setup_. E-mail to linux-omap@vger.kernel.org mailing list dated Wed, 30 Mar 2011 05:59:06 -0700. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47665.html 2. ibid.
Re: [PATCH] nohz: delay going tickless under CPU load to favor deeper C states
On 4/7/2011 11:18 AM, Kevin Hilman wrote: From: Nicole Chalhoubn-chalh...@ti.com While there is CPU load, continue the periodic tick in order to give CPUidle another opportunity to pick a deeper C-state instead of spending potentially long i so I don't really like this patch. It's actually a pretty bad hack (I'm sure it'll work somewhat) [and I mean that in the most positive sense of the word ;-) ] what we really need instead, and this is inside cpuidle, is the option to set a timer when we enter the non-deepest C state, so that if that timer fires we then reevaluate. The duration of that timer will be dependent on the C state (so should come from the C state structure of the state we pick). For the most shallow one this will be a relatively short time, but for the deepest-but-one this might be a lot longer time. your patch abuses a completely different, unrelated timer for this, with a pretty much unspecified frequency, that also has other side effects that we probably don't want. it shouldn't be hard to do the right thing instead and make it a separate timer with a per C state timeout. (and I would say a default timeout of 10x the break even time that we already have in the structure) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap: USB host disconnects connecting a device through USB HUB
Hi, 2011/4/7 Alan Stern st...@rowland.harvard.edu: On Thu, 7 Apr 2011, Enric Balletbò i Serra wrote: Hi all, I'm experimenting some issues with USB on IGEP v2 board, in certain cases I've an USB disconnect when I plug a device. For me it fails with kernel 2.6.35 but I think it also affect newer kernel, the issue is easy to reproduce following these steps: 1. Power up the board (without any device connected ) 2. When kernel is up, connect a powered USB HUB 2.0 to the USB host port, kernel shows, usb 1-1: new high speed USB device using ehci-omap and address 2 usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.4: new high speed USB device using ehci-omap and address 3 usb 1-1.4: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1.4: Product: USB2.0 Hub hub 1-1.4:1.0: USB hub found hub 1-1.4:1.0: 4 ports detected 3. Then if I connect a device (for example a pendrive) to the HUB I get USB disconnect message usb 1-1: USB disconnect, address 2 usb 1-1.4: USB disconnect, address 3 OTOH, it works without problem 1. if power up the board with the USB HUB connected to the USB Host port and the device connected to the USB hub. 2. if after kernel is up, connect the USB HUB + device to the USB Host port Anyone is experimenting something like this with other OMAP3-based boards ? At first glance, it looks like a power-related issue. Current inrush when the device is plugged in, or something like that. What happens if you attach the hub and pendrive to a standard PC? With standard PC works as expected, would be possible a problem with omap-ehci driver ? Maybe Felipe can give some light ? 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: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
On Thursday, April 07, 2011, Kevin Hilman wrote: Kevin Hilman khil...@ti.com writes: [...] Replacing the PM ops for all devices was done on OMAP and SH-mobile because that was the only approach we had. Now that we have device power domains (thanks Rafael!), we can be more selective about which devices to apply them to. Note that my RFC patch/series did not do the selective part of deciding which devices to override and which ones not to, that part will be platform specific. Actually, thinking about this a little more, my patch actually does select only relevant devices, and not *all* platform devices. In my patch, the device power domain pointers are only added for devices where a clk_get() actually succeeds. In the original version, the runtime PM hooks are overridden for *all* platform devices, but ones that have no clock (or where clk_get() failed) have the additional overhead of still calling the custom PM ops, but the custom ops have nothing to do. As I wrote in another message to Grant, the problem basically is that the platform bus type behavior is not the desirable one. Namely, I don't generally want device driver callbacks to be invoked until we know that power will be removed from the devices. However, the platform bus type executes driver callbacks automatically if they exist. This currently is unavoidable, because power domain callbacks are executed in addition to and not instead the bus type callbacks. We've discussed that a bit at the LF Collab Summit with Grant and Paul and the conclusion is that to address this particular problem we'll need to change the core so that if there is a power domain for the given device, the power domain callbacks will be executed first and if they return a specific error code, the core will execute the bus type callbacks. For devices that don't belong to any power domain, the bus type callbacks will be executed (which is the current behavior). I'm going to post a patch along these lines early next week. Then, we can simply move the management of device clocks, the execution of device driver callbacks and the power removal into power domain callbacks. At that point it may be possible to share some code between shmobile and OMAP, but I'm not sure yet how much of the code may be shared and it what way exactly. Thanks, Rafael -- 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/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms
On Thursday, April 07, 2011, Kevin Hilman wrote: Paul Mundt let...@linux-sh.org writes: On Wed, Apr 06, 2011 at 05:02:47PM -0700, Kevin Hilman wrote: There is really nothing SH-mobile specific about this runtime PM implementation. Any platform wanting to implement runtime PM based on simple clock gating can use this implementation. Signed-off-by: Kevin Hilman khil...@ti.com This observation is wholly architecture agnostic, so it's not clear that keeping it in arch/arm/common is any better. It seems that this would be better suited for drivers/base/power/ with a generic Kconfig symbol. Sounds fine to me. Well, what platforms is the clock framework available on? Rafael -- 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] nohz: delay going tickless under CPU load to favor deeper C states
Hi Arjan, Arjan van de Ven ar...@linux.intel.com writes: On 4/7/2011 11:18 AM, Kevin Hilman wrote: From: Nicole Chalhoubn-chalh...@ti.com While there is CPU load, continue the periodic tick in order to give CPUidle another opportunity to pick a deeper C-state instead of spending potentially long i so I don't really like this patch. It's actually a pretty bad hack (I'm sure it'll work somewhat) [and I mean that in the most positive sense of the word ;-) ] I'll take it as a complement then. :) I agree though, it did feel somewhat like we were attempting to fix the problem in the wrong place. what we really need instead, and this is inside cpuidle, is the option to set a timer when we enter the non-deepest C state, so that if that timer fires we then reevaluate. The duration of that timer will be dependent on the C state (so should come from the C state structure of the state we pick). OK, this sounds like a good idea. Will experiment. Of course, setting new timers can affect the governors decision. To avoid that, I guess this timer will need to be one-shot, and only set after the CPUidle governor has made a decision, otherwise that timer itself will affect tick_nohz_get_sleep_length() which the governor uses to pick a C-state. For the most shallow one this will be a relatively short time, but for the deepest-but-one this might be a lot longer time. your patch abuses a completely different, unrelated timer for this, with a pretty much unspecified frequency, that also has other side effects that we probably don't want. What side effects come to mind? The only side effects that I could think of were (potentially) unwanted wakeups from C1. However, since C1 is presumably cheap to enter (and exit), it seemed like a worthwhile cost since you're almost certain to pick a deeper C state after wakeup. That being said, your idea of per C-state timer is much better than relying on the scheduler tick. On most ARM systems, HZ is still pretty low (around 100), the time between ticks is relatively long, but on a HZ=1000 setup, I could see the extra wakeups having a penalty of their own. it shouldn't be hard to do the right thing instead and make it a separate timer with a per C state timeout. Agreed. Will give it a try. (and I would say a default timeout of 10x the break even time that we already have in the structure) OK. Thanks for the review and suggestions, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations
Rafael J. Wysocki r...@suse.com writes: On Thursday, April 07, 2011, Kevin Hilman wrote: Kevin Hilman khil...@ti.com writes: [...] Replacing the PM ops for all devices was done on OMAP and SH-mobile because that was the only approach we had. Now that we have device power domains (thanks Rafael!), we can be more selective about which devices to apply them to. Note that my RFC patch/series did not do the selective part of deciding which devices to override and which ones not to, that part will be platform specific. Actually, thinking about this a little more, my patch actually does select only relevant devices, and not *all* platform devices. In my patch, the device power domain pointers are only added for devices where a clk_get() actually succeeds. In the original version, the runtime PM hooks are overridden for *all* platform devices, but ones that have no clock (or where clk_get() failed) have the additional overhead of still calling the custom PM ops, but the custom ops have nothing to do. As I wrote in another message to Grant, the problem basically is that the platform bus type behavior is not the desirable one. Namely, I don't generally want device driver callbacks to be invoked until we know that power will be removed from the devices. Ah, I didn't know that was a goal. I totally agree there. However, the platform bus type executes driver callbacks automatically if they exist. This currently is unavoidable, because power domain callbacks are executed in addition to and not instead the bus type callbacks. We've discussed that a bit at the LF Collab Summit with Grant and Paul and the conclusion is that to address this particular problem we'll need to change the core so that if there is a power domain for the given device, the power domain callbacks will be executed first and if they return a specific error code, the core will execute the bus type callbacks. For devices that don't belong to any power domain, the bus type callbacks will be executed (which is the current behavior). I'm going to post a patch along these lines early next week. Then, we can simply move the management of device clocks, the execution of device driver callbacks and the power removal into power domain callbacks. Sounds good to me. At that point it may be possible to share some code between shmobile and OMAP, but I'm not sure yet how much of the code may be shared and it what way exactly. I'll have a look again after you post your series, but I'm pretty sure any runtime PM implementation based on basic clock gating could be shared. Basically, the idea is in the absence of real power domains, to create a default virtual powerdomain that contains every device with a clock. This would capture all on-chip devices into a single power domain. The device powerdomain callbacks for these would do the basic clock gating (as is done in mach-shmobile/pm_runtime.c). Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms
Rafael J. Wysocki r...@sisk.pl writes: On Thursday, April 07, 2011, Kevin Hilman wrote: Paul Mundt let...@linux-sh.org writes: On Wed, Apr 06, 2011 at 05:02:47PM -0700, Kevin Hilman wrote: There is really nothing SH-mobile specific about this runtime PM implementation. Any platform wanting to implement runtime PM based on simple clock gating can use this implementation. Signed-off-by: Kevin Hilman khil...@ti.com This observation is wholly architecture agnostic, so it's not clear that keeping it in arch/arm/common is any better. It seems that this would be better suited for drivers/base/power/ with a generic Kconfig symbol. Sounds fine to me. Well, what platforms is the clock framework available on? Well, the majority of implementations of linux/clk.h are certainly in ARM, but I know it's also implemented for SH, and a quick grep shows implementations in powerpc, mips and m68k also. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
Dears,
I cannot understand how TLS EMU ensure it's SMP safe, because get_tls
helper (at 0x0fe0) just read the value from 0x0ff0. But all
SMP cores should have the exact same mapping to the vectors page (at
0x). So various threads running on different SMP cores at the
same time would get the same emulated TLS value (instead of thread
specific value set via set_tls). Could anybody explain this a little
bit?
Thanks,
Lea
On Mon, Jul 5, 2010 at 9:55 PM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [100702 13:32]:
* Nicolas Pitre n...@fluxnic.net [100702 05:31]:
On Thu, 1 Jul 2010, Jamie Lokier wrote:
Tony Lindgren wrote:
+static void __init kuser_get_tls_init(unsigned long vectors)
+{
+ /*
+ * vectors + 0xfe0 = __kuser_get_tls
+ * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8
+ */
+ if (tls_emu || has_tls)
+ memcpy((void *)vectors + 0xfe0, (void *)vectors +
0xfe8, 4);
+}
Just a little opinion: Perhaps has_tls_reg would be a clearer name.
All variants have TLS after all.
Good point.
I like that too. Updated patch below.
I've uploaded this patch into Russell's patch system:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6207/1
Jamie, assuming no more comments, do you care to Ack/Reviewed/Tested-by
the patch in the link above?
Regards,
Tony
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/RFC 4/6] ARM: move SH-mobile runtime PM to arm/common for sharing with other platforms
On Thu, Apr 07, 2011 at 05:38:38PM -0700, Kevin Hilman wrote: Rafael J. Wysocki r...@sisk.pl writes: On Thursday, April 07, 2011, Kevin Hilman wrote: Paul Mundt let...@linux-sh.org writes: This observation is wholly architecture agnostic, so it's not clear that keeping it in arch/arm/common is any better. It seems that this would be better suited for drivers/base/power/ with a generic Kconfig symbol. Sounds fine to me. Well, what platforms is the clock framework available on? Well, the majority of implementations of linux/clk.h are certainly in ARM, but I know it's also implemented for SH, and a quick grep shows implementations in powerpc, mips and m68k also. We also have CONFIG_HAVE_CLK that can be used as a dependency. In any event, anything simply focusing on the clock bits can be completely generic. On SH we still have these things lumped together with hwblk IDs, but this is something we can likely transition off of with power domains. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 DSS clock setup
Hi Paul, On Thu, 2011-04-07 at 13:27 -0600, Paul Walmsley wrote: Hello Tomi, Benoît, On Mon, 4 Apr 2011, Tomi Valkeinen wrote: On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote: Based on the E-mail thread so far, I'd say that changing the clock aliases is the way to go for right now. The clock aliases are not hardware data; they just control how the clock hardware is mapped to the drivers. I'd very much prefer this option. Below is a patch for this. If Benoit doesn't complain too much about this, I'd like to get this merged as soon as possible, as OMAP4 DSS is currently crashing in the mainline kernel. I will queue your clock aliases patch and attempt to merge it upstream for the -rc series. I am not happy to be disagreeing with Benoît here, but this is the rationale that I am using. (Benoît, Tomi, please feel free to correct if there is something blatantly false below.) 1. The integration of the DSS module is an unusual case. The MODULEMODE bits for the DSS bits do not control the DSS main functional clock (the clock that is needed to access device registers); instead, they only control the DSS interface clock. (This is because the DSS can use a functional clock that is not provided by the OMAP core.) So calling the DSS MODULEMODE struct clk dss_fck is not really correct, since it is really controlling the interface clock. If we don't apply the patch, I think the clock aliases are still broken. Let's forget the ick/fck thing for a second, and just think the clock from PRCM which is used as the source clock for pixel clock. That is currently called fck on OMAP2/3, but dss_dss_clk on OMAP4. This cannot be right, can it? From DSS's point of view that is the same clock, it should clearly have the same alias on all platforms. I don't care what the name is as long as it's consistent on all platforms. And I have to say I still don't quite get it what is the problem with fck name. Or is that meant to be a clock which enables the registers on the module, and not the clock used for the pixel clock? If so, I'm fine with having fck to be what it is currently, but then we need a new name for the clock used for pixel clock, which is consistent on all platforms. 2. This patch does not create a precedent for hacking around general driver clocking problems in the clock or clock data. This is only needed because the MODULEMODE bits don't control the module functional clock in this case. As I understand it, the only other device that this problem could occur with is McBSP, due to mcbsp_clks. 3. The existing DSS2 driver clock design apparently works fine when this change is implemented[1], so no driver changes will be needed. 4. The proposed DSS driver patch to work around this uses a nasty hack that really should be NACK'ed[2]. All this said, we may not be able to merge this change upstream, due to the recent unhappiness about the clock data changes. If Linus rejects it, you'll need a Plan B. ... Also, I hope you and the other DSS hackers can finish the PM runtime conversion of the DSS driver soon. Ideally before any new DSS features are added. We really need to be able to separate the OMAP integration details from the drivers, and right now, hwmod and PM runtime are the best way we have to do that. I also started to look at the PM runtime, but it doesn't fix the issue with the inconsistent clock name I described above. I also have some questions regarding PM runtime, perhaps I'll just put them here as they are slightly related: - Should every DSS module handle their clocks independently, i.e. should VENC get its own clocks and DSI should get its own? If so, we need a bunch of new clock aliases so the devices can get their clocks. - Should every DSS module have their own PM runtime handling? (actually related to the question above) - If the modules are handled separately, how should the dependencies be handled? For example, dss_core's reset will reset all the other modules also, and most of the submodules need functions from dss_core and dss_dispc. So should, say, dss_dsi then call functions in core and dispc to get them, i.e. increase their pm runtime use count? - There seems to be some child/parent relationships in PM runtime. Should dss_core be the parent for the rest of the DSS modules? This would at least solve the reset issue easily, I guess. - How does saving/restoring the registers for OFF mode go with PM runtime? Should the registers be saved in runtime_suspend(), and restored in runtime_resume()? Can/should omap_pm_get_dev_context_loss_count() still be used to optimize the restoring? Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
