Re: [PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
Is this specific to some boards or all board with TI81xx ?
What is the side-effect if not done ?
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 eb3e4d5... 00c658b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 c3e96a2... 0e14834... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30
+++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index eb3e4d5..00c658b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -127,6 +127,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c3e96a2..0e14834 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -90,6 +91,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -490,6 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -497,7 +500,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -508,6 +512,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing
Re: [PATCH 2/2] mmc: omap_hsmmc: cleanup the bitmap definitions of Interrupt Register
On Tue, Aug 28, 2012 at 6:49 PM, Venkatraman S svenk...@ti.com wrote:
Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).
Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled by default.
No functional changes.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 51
---
1 file changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 57e86a4..03c2362 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -79,28 +79,16 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
-#define INT_EN_MASK0x306E0033
-#define BWR_ENABLE (1 4)
-#define BRR_ENABLE (1 5)
-#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
-#define DMA_EN 0x1
+#define DMAE 0x1
This change is not needed or may not be part of this patch
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
#define DDR(1 19)
#define DW8(1 5)
-#define CC 0x1
-#define TC 0x02
#define OD 0x1
-#define ERR(1 15)
-#define CMD_TIMEOUT(1 16)
-#define DATA_TIMEOUT (1 20)
-#define CMD_CRC(1 17)
-#define DATA_CRC (1 21)
-#define CARD_ERR (1 28)
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD0x
#define DUAL_VOLT_OCR_BIT 7
@@ -109,6 +97,25 @@
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+/* Interrupt masks for IE and ISE register */
+#define CC_EN (1 0)
+#define TC_EN (1 1)
Minor comment:
You might want to retain CC, TC... instead of CC_EN as before.
CC_EN is not mentioned in TRM. It would be better to reuse CC
(similarly for other bits fields too) for MMCHS_IE, MMCHS_ISE
inorder to reduce the number of #define's
+#define BWR_EN (1 4)
+#define BRR_EN (1 5)
+#define ERR_EN (1 15)
ERR_EN is not applicable for Interrupt masks for IE and ISE register
+#define CTO_EN (1 16)
+#define CCRC_EN(1 17)
+#define CEB_EN (1 18)
+#define CIE_EN (1 19)
+#define DTO_EN (1 20)
+#define DCRC_EN(1 21)
+#define DEB_EN (1 22)
+#define CERR_EN(1 28)
+#define BADA_EN(1 29)
+
+#define INT_EN_MASK(BADA_EN | CERR_EN | DEB_EN | DCRC_EN | \
+ CIE_EN | CEB_EN | CCRC_EN | BRR_EN | BWR_EN | TC_EN | CC_EN)
+
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 40
@@ -453,7 +460,7 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
unsigned int irq_mask;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE);
+ irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
else
irq_mask = INT_EN_MASK;
@@ -673,8 +680,8 @@ static void send_init_stream(struct omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host-base, CMD, INIT_STREAM_CMD);
timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((reg != CC) time_before(jiffies, timeout))
- reg = OMAP_HSMMC_READ(host-base, STAT) CC;
+ while ((reg != CC_EN) time_before(jiffies, timeout))
+ reg = OMAP_HSMMC_READ(host-base, STAT) CC_EN;
OMAP_HSMMC_WRITE(host-base, CON,
OMAP_HSMMC_READ(host-base, CON) ~INIT_STREAM);
@@ -765,7 +772,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
}
if (host-use_dma)
- cmdreg |= DMA_EN;
+ cmdreg |= DMAE;
In that case, this change can be avoided and in couple of other places too ...
host-req_in_progress = 1;
@@ -988,11 +995,11 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
data = host-data;
dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
- if (status ERR) {
+ if (status ERR_EN) {
omap_hsmmc_dbg_report_irq(host, status);
- if (status (CMD_TIMEOUT | DATA_TIMEOUT))
+ if (status (CTO_EN | DTO_EN))
hsmmc_command_incomplete(host, -ETIMEDOUT);
-
Re: [PATCH 07/10] mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S svenk...@ti.com wrote:
Flushing spurious IRQs from HSMMC IP is done twice in
omap_hsmmc_irq and omap_hsmmc_do_irq.
spurious IRQ is flushed in start of omap_hsmmc_do_irq
and irq acked at the end of omap_hsmmc_do_irq
Consolidate them to one location.
if you wanted to consolidated ...
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4bc55ac..20453c8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -969,15 +969,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0;
- if (!host-req_in_progress) {
just do a return from here
- do {
- OMAP_HSMMC_WRITE(host-base, STAT, status);
- /* Flush posted write */
- status = OMAP_HSMMC_READ(host-base, STAT);
- } while (status INT_EN_MASK);
- return;
- }
-
data = host-data;
dev_vdbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
@@ -1028,8 +1019,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
}
}
- OMAP_HSMMC_WRITE(host-base, STAT, status);
-
if (end_cmd || ((status CC) host-cmd))
omap_hsmmc_cmd_done(host, host-cmd);
if ((end_trans || (status TC)) host-mrq)
@@ -1045,11 +1034,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- do {
+ while (status INT_EN_MASK host-req_in_progress) {
and remove the check for host-req_in_progress
I think do while loop can be retained as it will get executed once anyway.
omap_hsmmc_do_irq(host, status);
+
/* Flush posted write */
comment is misplaced
+ OMAP_HSMMC_WRITE(host-base, STAT, status);
status = OMAP_HSMMC_READ(host-base, STAT);
- } while (status INT_EN_MASK);
+ }
return IRQ_HANDLED;
}
--
1.7.11.1.25.g0e18bef
--
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: am3517: geting MMC working
On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 19 Jul 2012, S, Venkatraman wrote: From this, one can only infer that the card is not responding at all, and all attempts are returning with a timeout (CTO=Command Time Out). Looks to me like the card is responding to CMD8, CMD55, ACMD41, and CMD0. It's only CMD52 and CMD5 that are timing out. Aren't those timeouts expected with a SD memory card? yes, those timeouts are expected for SD card. The failure is due to irq not received/missing for last CMD0. Hi Yegor, Can you provide details for the SD card being used. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 2:27 PM, S, Venkatraman svenk...@ti.com wrote: On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Waiting for root device /dev/mmcblk0p2... mmc0: starting CMD0 arg flags 00c0 omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x From this, one can only infer that the card is not responding at all, and all attempts are returning with a timeout (CTO=Command Time Out). These (control) commands don't use DMA, so it's not a DMA issue upto this. If the card is fine, and it worked before, I would suggest a bisect. Meanwhile I'll check lo-master with my OMAP4 boards. ~Venkat I checked on 4430sdp, OMAP4 is able to detect both eMMC and SD with lo-master. -- Thanks and Regards, Balaji T K -- 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: PM/RTC 3.5-rc5: System suspends fails when not built with RTC?
On Wed, Jul 11, 2012 at 4:20 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Kevin Hilman khil...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: linux-omap\@vger.kernel.org linux-omap@vger.kernel.org Date: Tue, 10 Jul 2012 16:58:18 -0700 Subject: Re: PM/RTC 3.5-rc5: System suspends fails when not built with RTC? Joe Woodward j...@terrafix.co.uk writes: I've got 3.5-rc5 with the following patches applied to get system suspend working on OMAP3: - fix the DSS: OMAPDSS: Use PM notifiers for system suspend - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer This has been built with the omap2plus_defconfig. However, If I disable the RTC (i.e. CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) and rebuild then when suspending the device never wakes up. That is, I can't get any wakeups to happen (either through the console, or GPIO buttons) hence I'm assuming the kernel has crashed... Any ideas? As far as I know there is no dependency on the RTC in 3.4, and with the RTC compiled in I never see a problem on 3.5-rc5. There is definitely a bug in the EHCI driver in v3.5 that cause a hang in suspend, but the RTC connection is very strange. I was not able to reproduce this. Can you try the same with my current 'pm' branch[1]. I've got a handful of additional fixes there for various other problems where both MMC and EHCI are preventing sucessful suspend with the default omap2plus_defconfig. (note the EHCI fix is simply diabling it in the defconfig.) Kevin Hi Kevin, Thanks for looking in to this. I've taken a copy of the PM branch with tag pm-20120710 and built with omap2plus_defconfig. But I get several warnings during boot, and suspend works - but almost nothing enters the target states: Warnings include: [0.00] clockdomain: mpu_clkdm: powerdomain ¬õ`À8ºsÀ does not exist [2.311004] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk [2.317382] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 [2.325256] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk [2.331512] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 Hi Joe, This warning should go away with CONFIG_DMA_OMAP, CONFIG_DMA_ENGINE enabled [2.447784] platform omap_hsmmc.0: omap_device_late_idle: enabled but no driver. Idling [2.456359] platform omap_hsmmc.1: omap_device_late_idle: enabled but no driver. Idling -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] mmc: omap: driver registration cleanups
On Tue, May 8, 2012 at 5:05 PM, Venkatraman S svenk...@ti.com wrote: Cleanups for the legacy omap mmc driver to remove clutter and make it well behaved as module. Venkatraman S (3): mmc: omap: convert to per instance workqueue mmc: omap: make it behave well as module mmc: omap: convert to module_platform_driver Looks good to me, So Acked-by: Balaji T K balaj...@ti.com drivers/mmc/host/omap.c | 48 +++--- 1 files changed, 16 insertions(+), 32 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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: [RFC 00/12] OMAP DMA engine conversion
On Mon, Apr 23, 2012 at 9:34 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: For the full text, please see http://lists.arm.linux.org.uk/lurker/message/20120418.100954.7fa7acf8.en.html This version contains updates for some of the comments received from the previous round, and adds the OMAP1/2 MMC and SPI drivers to the conversion. Tested eMMC, SD on omap4 Blaze Tested-by: Balaji T K balaj...@ti.com I've also added a note to feature-removal noting that the existing APIs will be removed around 2013 - I'm planning January for that at the moment. Having drivers around which are unconverted blocks further work on the DMA engine conversion, so it's actually important that we get as many drivers converted as soon as possible. Anything which isn't converted will probably have its DMA code removed, or if that results in the driver not being usable, the driver itself will be removed. This series is still in RFC mode... Documentation/feature-removal-schedule.txt | 11 + arch/arm/mach-omap1/board-h2-mmc.c | 1 - arch/arm/mach-omap1/board-h3-mmc.c | 1 - arch/arm/mach-omap1/board-nokia770.c | 1 - arch/arm/mach-omap2/board-n8x0.c | 1 - arch/arm/mach-omap2/hsmmc.c | 1 - arch/arm/plat-omap/dma.c | 14 + arch/arm/plat-omap/include/plat/mmc.h | 2 - drivers/dma/Kconfig | 10 + drivers/dma/Makefile | 2 + drivers/dma/omap-dma.c | 521 drivers/dma/sa11x0-dma.c | 249 - drivers/dma/virt-dma.c | 99 ++ drivers/dma/virt-dma.h | 138 drivers/mmc/host/omap.c | 369 +--- drivers/mmc/host/omap_hsmmc.c | 206 ++-- drivers/spi/spi-omap2-mcspi.c | 228 +++-- 17 files changed, 1268 insertions(+), 586 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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 v2] arm: omap4: hsmmc: check for null pointer
On Mon, Apr 23, 2012 at 8:13 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Apr 23, 2012 at 08:11:07PM +0530, Balaji T K wrote:
+int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
+{
+ struct omap2_hsmmc_info *c;
+
+ omap_hsmmc_init(controllers);
+ for (c = controllers; c-mmc; c++) {
+ /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!c-pdev)
+ continue;
+ omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
+ }
+
+ return 0;
+}
why are you even calling this if CONFIG_MMC_OMAP_HS isn't set ? Just
stub it out if you don't have mmc support.
Ok, added in v3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, Apr 20, 2012 at 3:03 PM, Tero Kristo t-kri...@ti.com wrote: Hi, First version for this work. Applies on top of mainline + iochain set + OMAP4 core retention set. Working tree available here: tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.4-omap4-dev-off Tested on omap4430 EMU blaze + omap4460 GP panda boards. Some drivers have issues with device off, most notably MMC, as it breaks device off on blaze device after 1 entry to device off mode: [ 208.906921] omap_i2c omap_i2c.1: XRDY IRQ while no data to send [ 209.905639] omap_i2c omap_i2c.1: controller timed out [ 209.905792] twl: i2c_read failed to transfer all messages [ 209.905792] omap_hsmmc omap_hsmmc.1: could not set regulator OCR (-110) [ 212.296203] mmc0: error -110 during resume (card was removed?) Hi Tero, I tried your branch on gp/emu devices but could not reproduce this issue. My observation is that while resuming, omap_hsmmc.1 eMMC is trying to turn on phoenix vaux1 regulator via i2c which fails due to controller timeout. Note: eMMC is present only on sdp/blaze [ 212.562164] PM: resume of devices complete after 3656.007 msecs [ 212.660125] Restarting tasks ... done. # # echo mem /sys/power/state [ 220.376892] PM: Syncing filesystems ... done. [ 220.382476] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 220.408386] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 220.439605] Suspending console(s) (use no_console_suspend to debug) [ 220.454650] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -110 [ 220.454711] PM: Device omap_hsmmc.1 failed to suspend: error -110 [ 220.454711] PM: Some devices failed to suspend [ 220.718261] PM: resume of devices complete after 263.539 msecs [ 220.743988] Restarting tasks ... done. Attempting to disable MMC from config prevented boot completely for me, so this issue is likely to stay until someone fixes the MMC driver. Panda device works fine though, although the wakeup from device off is slow due to problems with some other drivers (most likely I2C.) can you try this patch if you want to disable MMC http://permalink.gmane.org/gmane.linux.ports.arm.omap/74540 or http://www.spinics.net/lists/linux-omap/msg67879.html and build omap_hsmmc as module. Off mode is disabled by default, it can be enabled by either calling omap4_pm_enable_off_mode(1) from board files or alternatively writing to a debugfs node from userspace: echo 1 /debug/pm_debug/enable_off_mode Device off entry can be tracked through the debugfs also, it increases the core_pwrdm OFF state counter / timer, as this is an invalid state for the chip normally (core enters OSWR in device off.) Not sure if this a good way to do this but comments are welcome. -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 -- 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 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization
On Wed, Apr 18, 2012 at 3:42 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
DMAengine uses the DMA engine device structure when mapping/unmapping
memory for DMA, so the MMC devices do not need their DMA masks
initialized (this reflects hardware: the MMC device is not the device
doing DMA.)
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-omap1/board-h2-mmc.c | 1 -
arch/arm/mach-omap1/board-h3-mmc.c | 1 -
arch/arm/mach-omap1/board-nokia770.c | 1 -
arch/arm/mach-omap2/board-n8x0.c | 1 -
arch/arm/mach-omap2/hsmmc.c | 1 -
arch/arm/plat-omap/include/plat/mmc.h | 2 --
Hi,
drivers/mmc/host/omap.c is also using dma_mask should that also be removed
6 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
b/arch/arm/mach-omap1/board-h2-mmc.c
index da0e37d..e1362ce 100644
--- a/arch/arm/mach-omap1/board-h2-mmc.c
+++ b/arch/arm/mach-omap1/board-h2-mmc.c
@@ -54,7 +54,6 @@ static struct omap_mmc_platform_data mmc1_data = {
.nr_slots = 1,
.init = mmc_late_init,
.cleanup = mmc_cleanup,
- .dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
diff --git a/arch/arm/mach-omap1/board-h3-mmc.c
b/arch/arm/mach-omap1/board-h3-mmc.c
index f8242aa..c74daac 100644
--- a/arch/arm/mach-omap1/board-h3-mmc.c
+++ b/arch/arm/mach-omap1/board-h3-mmc.c
@@ -36,7 +36,6 @@ static int mmc_set_power(struct device *dev, int slot, int
power_on,
*/
static struct omap_mmc_platform_data mmc1_data = {
.nr_slots = 1,
- .dma_mask = 0x,
.slots[0] = {
.set_power = mmc_set_power,
.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index d21dcc2..cac9954 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -185,7 +185,6 @@ static int nokia770_mmc_get_cover_state(struct device
*dev, int slot)
static struct omap_mmc_platform_data nokia770_mmc2_data = {
.nr_slots = 1,
- .dma_mask = 0x,
.max_freq = 1200,
.slots[0] = {
.set_power = nokia770_mmc_set_power,
diff --git a/arch/arm/mach-omap2/board-n8x0.c
b/arch/arm/mach-omap2/board-n8x0.c
index 518091c..1003748 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -470,7 +470,6 @@ static struct omap_mmc_platform_data mmc1_data = {
.cleanup = n8x0_mmc_cleanup,
.shutdown = n8x0_mmc_shutdown,
.max_freq = 2400,
- .dma_mask = 0x,
.slots[0] = {
.wires = 4,
.set_power = n8x0_mmc_set_power,
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b0268ea..41e5277 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -315,7 +315,6 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-slots[0].caps = c-caps;
mmc-slots[0].pm_caps = c-pm_caps;
mmc-slots[0].internal_clock = !c-ext_clock;
- mmc-dma_mask = 0x;
mmc-max_freq = c-max_freq;
if (cpu_is_omap44xx())
mmc-reg_offset = OMAP4_MMC_REG_OFFSET;
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 7a38750..9fe87a7 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -80,8 +80,6 @@ struct omap_mmc_platform_data {
/* Return context loss count due to PM states changing */
int (*get_context_loss_count)(struct device *dev);
- u64 dma_mask;
-
/* Integrating attributes from the omap_hwmod layer */
u8 controller_flags;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 8/8] ARM: omap_hsmmc: remove platform data dma_mask and initialization
On Wed, Apr 18, 2012 at 8:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Apr 18, 2012 at 08:53:32PM +0530, T Krishnamoorthy, Balaji wrote: Hi, drivers/mmc/host/omap.c is also using dma_mask should that also be removed Does this driver make use of this platform data? If so, it needs converting to DMA engine _before_ this patch (which is one reason why its a good idea to do these changes as separate patches... as I've done.) It means stuff like this can be slotted in as necessary in the patch order. I'm told that driver is OMAP2 only - I don't have any OMAP2 platforms to be able to test it on (I only have OMAP3 and OMAP4.) Yes, this driver is for omap2420 and omap1 devices. -- 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] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
On Wed, Apr 11, 2012 at 3:33 PM, Rajendra Nayak rna...@ti.com wrote:
of_have_populated_dt() is not expected to be used in drivers but
instead only in early platform init code.
Drivers on the other hand should rely on dev-of_node or of_match_device().
Besides usage of of_have_populated_dt() also throws up build error as below
which was reported by Balaji TK, when omap_hsmmc is built as a module.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
instead use dev-of_node to make the same dicisions as earlier.
Looks good to me
Reviewed-by: Balaji T K balaj...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji TK balaj...@ti.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ecc9521..4254b6f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
* the pbias cell programming support is still missing when
* booting with Device tree
*/
- if (of_have_populated_dt() !vdd)
+ if (dev-of_node !vdd)
return 0;
if (mmc_slot(host).before_set_reg)
@@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
* can't be allowed when booting with device
* tree.
*/
- (!of_have_populated_dt())) {
+ !host-dev-of_node) {
/*
* The mmc_select_voltage fn of the core does
* not seem to set the power_mode to
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap-hsmmc build broken with OF enabled in latest kernel
On Tue, Apr 10, 2012 at 7:33 PM, Chris Ball c...@laptop.org wrote:
Hi,
On Tue, Apr 10 2012, Russell King - ARM Linux wrote:
This commit:
commit 46856a68dcb5f67c779d211fd6bcb5d7a2a7f19b
Author: Rajendra Nayak rna...@ti.com
Date: Mon Mar 12 20:32:37 2012 +0530
mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract
data (which was earlier passed as platform_data) from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Chris Ball c...@laptop.org
breaks omap-hsmmc compilation:
drivers/mmc/host/omap_hsmmc.c:1745: error: expected ',' or ';' before
'extern'
+#ifdef CONFIG_OF
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
...
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
There should be a ';' after the }.
Thanks, and sorry for breaking the build. I've pushed a fix to mmc-next
and will send it out to Linus.
Surprisingly, this patch does not break my build with gcc-4.6.0 --
and I've just checked that line 1745 is being compiled by purposefully
introducing an(other) error to it, which *did* break my build. I wonder
what's going on there; presumably it's the reason that no-one else saw
this earlier.
Build fails iff omap_hsmmc is built as a module.
Adding ';' fixes and uncovers another build error due to unexported
variable allnodes, will send a RFC patch shortly.
ERROR: allnodes [drivers/mmc/host/omap_hsmmc.ko] undefined!
make[3]: *** [__modpost] Error 1
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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 RESEND 4/8] mmc: omap: context save after enabling runtime pm
On Thu, Mar 15, 2012 at 8:42 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
On Thursday 15 March 2012 08:03 PM, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
call context save api after enabling runtime pm
to make sure register access in context save api
If I am not mistaken the api would
store the number of power state changes and accesses no registers.
Am I missing something?
Yes, as of now no registers are accessed in context store. However
this patch is needed if registers are accessed in context save api.
happens with clk enabled.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0f8d34b..9fa2f39 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1871,8 +1871,6 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
goto err1;
}
- omap_hsmmc_context_save(host);
-
if (host-pdata-controller_flags OMAP_HSMMC_BROKEN_MULTIBLOCK_READ)
{
dev_info(pdev-dev, multiblock reads disabled due to 35xx
erratum 2.1.1.128; MMC read performance may suffer\n);
mmc-caps2 |= MMC_CAP2_NO_MULTI_READ;
@@ -1883,6 +1881,8 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
pm_runtime_set_autosuspend_delay(host-dev, MMC_AUTOSUSPEND_DELAY);
pm_runtime_use_autosuspend(host-dev);
+ omap_hsmmc_context_save(host);
+
if (cpu_is_omap2430()) {
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
/*
--
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/6] mmc: host: omap_hsmmc: trivial cleanups
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147
-
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..11fef49 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2104,30 +2104,28 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
Hi,
Checking for host NULL is added in suspend/resume, however it is missing in
.remove, is it intentional ?
+ pm_runtime_get_sync(host-dev);
+ mmc_remove_host(host-mmc);
+ if (host-use_reg)
+ omap_hsmmc_reg_put(host);
+ if (host-pdata-cleanup)
+ host-pdata-cleanup(pdev-dev);
+ free_irq(host-irq, host);
+ if (mmc_slot(host).card_detect_irq)
+ free_irq(mmc_slot(host).card_detect_irq, host);
- mmc_free_host(host-mmc);
- iounmap(host-base);
- omap_hsmmc_gpio_free(pdev-dev.platform_data);
+ pm_runtime_put_sync(host-dev);
+ pm_runtime_disable(host-dev);
+ clk_put(host-fclk);
+ if (host-got_dbclk) {
+ clk_disable(host-dbclk);
+ clk_put(host-dbclk);
}
+ mmc_free_host(host-mmc);
+ iounmap(host-base);
+ omap_hsmmc_gpio_free(pdev-dev.platform_data);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
release_mem_region(res-start, resource_size(res));
--
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/6] mmc: host: omap_hsmmc: trivial cleanups
On Thu, Mar 15, 2012 at 7:30 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 15, 2012 at 07:20:22PM +0530, T Krishnamoorthy, Balaji wrote:
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147
-
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..11fef49 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2104,30 +2104,28 @@ static int omap_hsmmc_remove(struct
platform_device *pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
Hi,
Checking for host NULL is added in suspend/resume, however it is missing in
.remove, is it intentional ?
you mean:
if (!host)
return 0;
???
That's intentional. We know platform_set_drvdata() is called on probe,
and we can only reach .remove if .probe was called first. So we can make
the assumption that dev-p-driver_data will always be valid on .remove.
If it isn't, it's a bug on driver core which we want to catch ASAP, so
it deserves to oops.
Agreed.
--
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 v2 0/4] omap hsmmc device tree support
On Mon, Mar 12, 2012 at 8:32 PM, Rajendra Nayak rna...@ti.com wrote: The series adds device tree support for OMAP hsmmc driver. Changes in V2: -1- Minor fixes based on comments from Grant. -2- Added a seperate compatible for omap3. -3- Added a new binding ti,needs-special-reset to handle some mmc modules which need special softreset sequence. -4- Updated board dts files with status = disable; for unused mmc modules. Rob, I retained your ack on patch 1 despite the additional binding that I added to handle the special softreset sequence. Let me know if you have any issues with it. Chris. Patch 1 and Patch 2 apply cleanly on mmc-next and can be taken in from the mmc tree after relevent acks from DT folks. Patch 3 and Patch 4 which update dts files, I plan to push via linux-omap/Tony's tree. Hi Rajendra, Tested this series on omap4sdp, so feel free to add Tested-by: Balaji T K balaj...@ti.com The series is tested on omap4sdp (both external and emmc), omap4panda amd omap3beagle boards. Things to do: -1- Card detect isn't functional and needs twl4030 gpio to be DT converted. -2- pbias cell programming is missing and needs an OMAP control module driver. Rajendra Nayak (4): mmc: omap_hsmmc: Convert hsmmc driver to use device tree mmc: omap_hsmmc: Avoid a regulator voltage change with dt arm/dts: OMAP4: Add mmc controller nodes and board data arm/dts: OMAP3: Add mmc controller nodes and board data .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 33 +++ arch/arm/boot/dts/omap3-beagle.dts | 14 +++ arch/arm/boot/dts/omap3.dtsi | 16 arch/arm/boot/dts/omap4-panda.dts | 22 + arch/arm/boot/dts/omap4-sdp.dts | 24 ++ arch/arm/boot/dts/omap4.dtsi | 31 +++ drivers/mmc/host/omap_hsmmc.c | 88 +++- 7 files changed, 227 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Wed, Mar 7, 2012 at 9:12 PM, Chris Ball c...@laptop.org wrote: Hi Balaji, On Wed, Mar 07 2012, T Krishnamoorthy, Balaji wrote: OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com Is this a regression, or has it never worked in mainline? Not a regression introduced in current merge window. It happens on re-insertion of module. will post a patch with $SUBJECT Note: eMMC detection is still failing on resertion due to card vcc power off on rmmod And this? This issue was hidden and uncovered after this fix. This problem is Vcc being powered off without sleep command. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Mon, Mar 5, 2012 at 3:55 PM, T Krishnamoorthy, Balaji balaj...@ti.com wrote: On Mon, Mar 5, 2012 at 2:46 PM, Rajendra Nayak rna...@ti.com wrote: On Friday 02 March 2012 10:52 PM, Tony Lindgren wrote: BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails to detect any cards, and then fails to unload. This works on omap3 just fine. Any ideas why that would be? Yeah, looks like thats broken. I am not sure whats going wrong though. I just enabled CONFIG_MMC_DEBUG and saw these logs below. Venkat/Balaji, care to look at this one? Let me check this OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- Note: eMMC detection is still failing on resertion due to card vcc power off on rmmod drivers/mmc/host/omap_hsmmc.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index fd0c661..4e1f8f6 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1870,8 +1870,6 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1896,7 +1894,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) host-irq = irq; host-id= pdev-id; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; host-next_data.cookie = 1; -- 1.7.0.4 # insmod omap_hsmmc.ko [ 43.358398] omap_hsmmc omap_hsmmc.0: context was not lost [ 43.364105] omap_hsmmc omap_hsmmc.0: enabled [ 44.434661] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 44.442352] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.474365] omap_hsmmc omap_hsmmc.0: disabled [ 44.482208] omap_hsmmc omap_hsmmc.4: context was not lost [ 44.482208] omap_hsmmc omap_hsmmc.4: enabled [ 44.546600] omap_hsmmc omap_hsmmc.0: context was not lost [ 44.552276] omap_hsmmc omap_hsmmc.0: enabled [ 44.552276] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz [ 44.563720] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 18 width 0 timing 0 [ 44.572174] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.613800] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 18 width 0 timing 0 [ 44.621887] omap_hsmmc omap_hsmmc.0: Set clock to 40Hz [ 44.735290] mmc0: starting CMD52 arg 0c00 flags 0195 [ 44.741271] omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x0c00 [ 45.560241] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 45.567871] omap_hsmmc omap_hsmmc.4: Set clock to 0Hz [ 45.591491] omap_hsmmc omap_hsmmc.4: disabled # # # rmmod omap_hsmmc [ 607.302307] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.308044] omap_hsmmc omap_hsmmc.4: enabled [ 607.312591] omap_hsmmc omap_hsmmc.4: disabled [ 607.317199] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.322875] omap_hsmmc omap_hsmmc.4: enabled -- Thanks and Regards, Balaji T K -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Mon, Mar 5, 2012 at 2:46 PM, Rajendra Nayak rna...@ti.com wrote: On Friday 02 March 2012 10:52 PM, Tony Lindgren wrote: BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails to detect any cards, and then fails to unload. This works on omap3 just fine. Any ideas why that would be? Yeah, looks like thats broken. I am not sure whats going wrong though. I just enabled CONFIG_MMC_DEBUG and saw these logs below. Venkat/Balaji, care to look at this one? Let me check this # insmod omap_hsmmc.ko [ 43.358398] omap_hsmmc omap_hsmmc.0: context was not lost [ 43.364105] omap_hsmmc omap_hsmmc.0: enabled [ 44.434661] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 44.442352] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.474365] omap_hsmmc omap_hsmmc.0: disabled [ 44.482208] omap_hsmmc omap_hsmmc.4: context was not lost [ 44.482208] omap_hsmmc omap_hsmmc.4: enabled [ 44.546600] omap_hsmmc omap_hsmmc.0: context was not lost [ 44.552276] omap_hsmmc omap_hsmmc.0: enabled [ 44.552276] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz [ 44.563720] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 18 width 0 timing 0 [ 44.572174] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.613800] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 18 width 0 timing 0 [ 44.621887] omap_hsmmc omap_hsmmc.0: Set clock to 40Hz [ 44.735290] mmc0: starting CMD52 arg 0c00 flags 0195 [ 44.741271] omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x0c00 [ 45.560241] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 45.567871] omap_hsmmc omap_hsmmc.4: Set clock to 0Hz [ 45.591491] omap_hsmmc omap_hsmmc.4: disabled # # # rmmod omap_hsmmc [ 607.302307] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.308044] omap_hsmmc omap_hsmmc.4: enabled [ 607.312591] omap_hsmmc omap_hsmmc.4: disabled [ 607.317199] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.322875] omap_hsmmc omap_hsmmc.4: enabled -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
serial1 = uart2;
serial2 = uart3;
serial3 = uart4;
+ mmc1 = mmc1;
+ mmc2 = mmc2;
+ mmc3 = mmc3;
+ mmc4 = mmc4;
+ mmc5 = mmc5;
};
cpus {
@@ -155,5 +160,31 @@
#size-cells = 0;
ti,hwmods = i2c4;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc2;
+ };
Hi Rajendra,
Is there a way to control the device registration order,
eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
irrespective of whether SD card is mount or not on mmc1 card slot.
So that bootargs would not have to be modified when filesystem is on eMMC.
+
+ mmc3: mmc@3 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data
On Fri, Feb 24, 2012 at 3:56 PM, Rajendra Nayak rna...@ti.com wrote:
On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
serial1 =uart2;
serial2 =uart3;
serial3 =uart4;
+ mmc1 =mmc1;
+ mmc2 =mmc2;
+ mmc3 =mmc3;
+ mmc4 =mmc4;
+ mmc5 =mmc5;
};
cpus {
@@ -155,5 +160,31 @@
#size-cells =0;
ti,hwmods = i2c4;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc2;
+ };
Hi Rajendra,
Is there a way to control the device registration order,
eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
irrespective of whether SD card is mount or not on mmc1 card slot.
So that bootargs would not have to be modified when filesystem is on eMMC.
I don't know if we can, but even if we could, we take care of the same
bootargs working on two boards (say sdp and panda) *if* on sdp I have my
filesystem on eMMC and on panda I have it on external card.
What happens if I want to use my filesystem on both boards on external
card?
While booting if SD card is present in the card slot, SD is detected
as /dev/mmcblk0
and eMMC as /dev/mmcblk1
If SD card is not present, then eMMC is detected as /dev/mmcblk0
When filesystem is in eMMC then bootargs has to switch between mmcblk0
or mmcblk1
depending on whether SD is present or not.
By changing the device order, eMMC will always be mmcblk0 independent
of SD card status.
+
+ mmc3: mmc@3 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak rna...@ti.com wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
omap_hsmmc is applicable for omap2430 and omap3.
omap2420 has non high speed controller mmci-omap - drivers/mmc/host/omap.c
May be omap3-hsmmc compatible with omap2430 ?
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+ mmc1: mmc@0x4809c000 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4809c000 0x400;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,bus-width = 4;
+ vmmc-supply = vmmc; /* phandle to regulator node */
+ ti,non-removable;
+ };
--
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/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
On Tue, Feb 7, 2012 at 3:32 PM, S, Venkatraman svenk...@ti.com wrote: On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayak rna...@ti.com wrote: This series mainly cleans up all instances of hardcoding's in the driver based on pdev-id. This is cleanup leading to the DT adaptation of omap_hsmmc driver. Patches are based on 3.3-rc2 and can be found here git://gitorious.org/omap-pm/linux.git omap_hsmmc_cleanup Tested the patches on my omap4 boards (panda and SDP) but haven't tested yet on omap3/2 since I did'nt have boards handy. So any testing on any omap3/2 boards is really appreciated. Tested this series on 2430SDP with FS on SD card I gave it a spin on Beagleboard-XM (OMAP3630) with root filesystem on the SD card, and checked again on 4430SDP. Tested-by: Venkatraman S svenk...@ti.com regards, Rajendra Balaji T K (3): mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channels mmc: omap_hsmmc: remove unused .set_sleep function mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host-id based hardcoding Rajendra Nayak (3): mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply arch/arm/plat-omap/include/plat/mmc.h | 2 - drivers/mmc/host/omap_hsmmc.c | 158 +++-- 2 files changed, 14 insertions(+), 146 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
Re: [PATCH] ARM: OMAP2+ i2c NACK without STP
On Tue, Jun 14, 2011 at 4:24 PM, Jan Weitzel j.weit...@phytec.de wrote:
On OMAP4 OMAP_I2C_STAT_NACK is causing a timeout on the next access.
The isr cleans all flags in OMAP_I2C_CON_REG by setting OMAP_I2C_CON_STP
OMAP_I2C_CON_STP is also set in omap_i2c_xfer_msg on the last message.
According to the TI TSR the sequence for OMAP_I2C_STAT_NACK and
OMAP_I2C_STAT_AL are nearly the same.
Removing the OMAP_I2C_CON_STP part in the isr fix the problem.
Tested on OMAP4430 and OMAP3530 (here NACK was not a problem)
Fixes also booting on 2430sdp.
Signed-off-by: Jan Weitzel j.weit...@phytec.de
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Balaji T K balaj...@ti.com
Can you please queue this patch
This patch has been tested in linux-omap tree
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=464fca36d98b97ccd05e4f200ab7483d3acc8345
---
drivers/i2c/busses/i2c-omap.c | 6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 58a58c7..670f2a2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -836,11 +836,9 @@ complete:
~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
- if (stat OMAP_I2C_STAT_NACK) {
+ if (stat OMAP_I2C_STAT_NACK)
err |= OMAP_I2C_STAT_NACK;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
- OMAP_I2C_CON_STP);
- }
+
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hsmmc: add max_freq field
On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack zon...@gmail.com wrote: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 101cd31..8215ef9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (mmc_slot(host).vcc_aux_disable_is_sleep) mmc_slot(host).no_off = 1; - mmc-f_min = OMAP_MMC_MIN_CLOCK; - mmc-f_max = OMAP_MMC_MAX_CLOCK; + mmc-f_min = OMAP_MMC_MIN_CLOCK; Stray change for f_min ? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] TWL6030: Add mapping for auxiliary regs
On Thu, Dec 1, 2011 at 5:44 AM, Sergio Aguirre saagui...@ti.com wrote:
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/mfd/twl-core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index bfbd660..e26b564 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -323,7 +323,7 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
- { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
+ { SUB_CHIP_ID1, TWL6030_BASEADD_AUX },
Instead you can use TWL6030_MODULE_ID1, with base address as
zero for all registers in auxiliaries register map.
{ SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
--
1.7.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
--
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 v8 00/24] gpio/omap: driver cleanup and fixes
On Tue, Nov 29, 2011 at 8:45 PM, Kevin Hilman khil...@ti.com wrote: DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Fri, Nov 4, 2011 at 2:57 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Fri, Nov 4, 2011 at 3:14 AM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: This series is continuation of cleanup of OMAP GPIO driver and fixes. Using this series on 3630/Zoom3, UART wakeups no longer work from suspend. That suggests that GPIO wakeups from retention/off are not working. Please test GPIO wakeups from retention/off. One way is to use Zoom3 UART wakeup from suspend using by enabling UART wakeups and suspending: # echo enabled /sys/devices/platform/serial8250.0/tty/ttyS0/power/wakeup # echo mem /sys/power/state Ok, I will test and make necessary fix. I have done retention test of the latest series on Zoom3. When I try running off mode test it says support is not present because of an errata. Specifically, CORE off is not supported on that rev of 36xx due to an errata. Can you try on a newer 36xx? Here is the overall log: The rest of the dump seems to point to an MMC driver problem. Please take this with the MMC driver folks. Hi Tarun, Can you try with this patch queued in mmc-next for MMC warning http://article.gmane.org/gmane.linux.kernel.mmc/10961 -- 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_hsmmc noisy/broken for suspend resume
On Fri, Nov 4, 2011 at 2:54 AM, Kevin Hilman khil...@ti.com wrote: Hello, Using Linus' master branch, I was testing PM functionality on OMAP3/4 and noticed that the MMC driver is now rather noisy during suspend on OMAP3[1], but seems to work. On OMAP4, MMC seems to prevent suspend/resume all together. I haven't found the root cause, but know that by not buidling the MMC driver, I have working suspend/resume again on OMAP4. Venkat, can you investigate this? For OMAP4, please use my for_3.2/omap4-pm branch which has the OMAP4 MPUSS retention support from Santosh. With 4430SDP I observed abort on accessing I2C registers probably i2c clock is not turned ON? echo mem /sys/power/state [ 41.971649] PM: Preparing system for mem sleep [ 41.976440] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 42.002838] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 42.033172] PM: Entering mem sleep [ 42.043212] omap_hsmmc omap_hsmmc.4: context was not lost [ 42.043212] omap_hsmmc omap_hsmmc.4: enabled [ 42.043212] mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 42.060852] omap_hsmmc omap_hsmmc.4: Set clock to 0Hz [ 42.066192] omap_device: omap_hsmmc.0: new worst case activate latency 0: 5310058 [ 42.074035] omap_hsmmc omap_hsmmc.0: context was not lost [ 42.074035] omap_hsmmc omap_hsmmc.0: enabled [ 42.074035] mmc1: starting CMD7 arg flags [ 42.090026] omap_hsmmc omap_hsmmc.0: mmc1: CMD7, argument 0x [ 42.096679] omap_hsmmc omap_hsmmc.0: IRQ Status is 1 [ 42.096710] mmc1: req done (CMD7): 0: [ 42.109008] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 42.116668] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 42.122009] omap_hsmmc omap_hsmmc.1: context was not lost [ 42.127655] omap_hsmmc omap_hsmmc.1: enabled [ 42.132171] mmc0: starting CMD7 arg flags [ 42.138000] omap_hsmmc omap_hsmmc.1: mmc0: CMD7, argument 0x [ 42.144653] omap_hsmmc omap_hsmmc.1: IRQ Status is 1 [ 42.144653] mmc0: req done (CMD7): 0: [ 42.159301] mmc0: starting CMD5 arg 00018000 flags 001d [ 42.165130] omap_hsmmc omap_hsmmc.1: mmc0: CMD5, argument 0x00018000 [ 42.171783] omap_hsmmc omap_hsmmc.1: IRQ Status is 1 [ 42.176971] omap_hsmmc omap_hsmmc.1: IRQ Status is 2 [ 42.176971] mmc0: req done (CMD5): 0: 0600 [ 42.189270] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 42.196929] TWL6030 IRQ 0x0 0x8 0x0 [ 42.203765] omap_hsmmc omap_hsmmc.1: Set clock to 0Hz [ 42.203765] PM: suspend of devices complete after 166.717 msecs [ 42.216003] omap_hsmmc omap_hsmmc.4: disabled [ 42.221801] omap_hsmmc omap_hsmmc.0: disabled [ 42.226379] omap_hsmmc omap_hsmmc.1: disabled [ 42.230926] PM: late suspend of devices complete after 14.923 msecs [ 42.237609] Disabling non-boot CPUs ... [ 42.241790] Unhandled fault: imprecise external abort (0x1406) at 0x4005a000 [ 42.241851] Internal error: : 1406 [#1] SMP [ 42.253509] Modules linked in: [ 42.256713] CPU: 0Not tainted (3.1.0-00165-g97d4c96-dirty #12) [ 42.256713] PC is at omap_i2c_wait_for_bb+0x88/0xa8 [ 42.268341] LR is at omap_i2c_wait_for_bb+0x10/0xa8 [ 42.273437] pc : [c0351d84]lr : [c0351d0c]psr: 4013 [ 42.273437] sp : ef9dfee8 ip : 7e58 fp : ef8f2c00 [ 42.273437] r10: 7e58 r9 : c035249c r8 : 0001 [ 42.285430] r7 : c0c0c43c r6 : c063e080 r5 : c063e080 r4 : ef8f2c00 [ 42.285430] r3 : r2 : 0028 r1 : 0028 r0 : 0080 [ 42.304504] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 42.304504] Control: 10c53c7d Table: af10404a DAC: 0017 [ 42.304504] Process twl6030-irq (pid: 251, stack limit = 0xef9de2f8) [ 42.304504] Stack: (0xef9dfee8 to 0xef9e) [ 42.329284] fee0: ef8f2ca8 c063e080 c03524c8 ef9dfef8 0001 [ 42.337829] ff00: ef997460 ef8f2c70 c02b7ce4 ef8f2c60 c063e080 c0c0c43c 0001 [ 42.337829] ff20: c035249c 7e58 0004 c0350188 ef9dff84 c0c0c454 0068 [ 42.354888] ff40: c0c0c3cc c0c0c3c4 c0c0c434 c02b7d2c 0008 c0c0c640 [ 42.363433] ff60: ef9dff84 c0c0c640 c047cba4 0027 0030 c02b8fc8 [ 42.363433] ff80: 6013 00d0 ef833d18 0002 0027 c02b8e88 [ 42.380493] ffa0: c0073628 0001 0027 dead4ead [ 42.380493] ffc0: c06d4a74 c05628f4 ef9dffd8 ef9dffd8 [ 42.380493] ffe0: ef833d18 ef833d18 c00735a0 c0015358 0013 c0015358 64946642 61340b38 [ 42.380493] [c0351d84] (omap_i2c_wait_for_bb+0x88/0xa8) from [c03524c8] (omap_i2c_xfer+0x2c/0x388) [ 42.415832] [c03524c8] (omap_i2c_xfer+0x2c/0x388) from [c0350188] (i2c_transfer+0xa8/0x118) [
Re: [PATCH 1/2] arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF
On Thu, Sep 29, 2011 at 9:50 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110929 07:11]:
MMC1 data line IO's are powered down in before set regulator function.
IO's should not be powered ON when regulator is OFF.
Keep the IO's in power pown mode after regulator OFF.
Delete incorrect comments which are not applicable for OMAP4.
Care to check how this is different from what I added into fixes
branch as commit 3fe8df93b0992199e3a0026fc51e90b705f94e40?
Is this a separate issue?
Yes.
commit 3fe8df93b fixes USBC1 configuration.
USBC1 IO was configured unnecessarily for MMC IO.
This patch keeps the MMC IO's in power down after regulator OFF
otherwise it generates VMODE_ERROR due to mismatch in input (regulator)
voltage and MMC IO drive voltage.
Tony
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Reported-by: Viswanath Puttagunta vi...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 097a42d..9cc2eb7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -129,15 +129,11 @@ static void omap4_hsmmc1_before_set_reg(struct device
*dev, int slot,
* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
* card with Vcc regulator (from twl4030 or whatever). OMAP has both
* 1.8V and 3.0V modes, controlled by the PBIAS register.
- *
- * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
- * is most naturally TWL VSIM; those pins also use PBIAS.
- *
- * FIXME handle VMMC1A as needed ...
*/
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg = ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK);
+ OMAP4_MMC1_PWRDNZ_MASK |
+ OMAP4_MMC1_PBIASLITE_VMODE_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
@@ -172,12 +168,6 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
reg = ~(OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
- } else {
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
- reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
- OMAP4_MMC1_PWRDNZ_MASK |
- OMAP4_MMC1_PBIASLITE_VMODE_MASK);
- omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 11/16] mmc: omap_hsmmc: ensure pbias configuration is always done
On Fri, May 6, 2011 at 2:44 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
Go through the driver's set_power() functions rather than
calling regulator_enable/disable() directly because otherwise
pbias configuration for MMC1 is not done.
Hi Chris,
Are you OK to queue this patch as bug fix. Rest of the patches of this
series is either
merged or not needed. Should I rebase and repost this alone ?
FWIW:
Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4f6e552..8aa9440 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -445,15 +445,14 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host
*host)
* framework is fixed, we need a workaround like this
* (which is safe for MMC, but not in general).
*/
- if (regulator_is_enabled(host-vcc) 0) {
- regulator_enable(host-vcc);
- regulator_disable(host-vcc);
- }
- if (host-vcc_aux) {
- if (regulator_is_enabled(reg) 0) {
- regulator_enable(reg);
- regulator_disable(reg);
- }
+ if (regulator_is_enabled(host-vcc) 0 ||
+ (host-vcc_aux regulator_is_enabled(host-vcc_aux))) {
+ int vdd = ffs(mmc_slot(host).ocr_mask) - 1;
+
+ mmc_slot(host).set_power(host-dev, host-slot_id,
+ 1, vdd);
+ mmc_slot(host).set_power(host-dev, host-slot_id,
+ 0, 0);
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] arm: omap4: hsmmc: pbias fixes
From: Balaji T K balaj...@ti.com Will resend this series as my email id is garbled. MMC1 pbias and speed control fix for SDMMC1 extended I/O cell Balaji T K (2): arm: omap4: hsmmc: Fix Pbias configuration on regulator OFF arm: omap4: hsmmc: configure SDMMC1_DR0 properly arch/arm/mach-omap2/hsmmc.c | 16 +++- 1 files changed, 3 insertions(+), 13 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
Re: [PATCH] OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
Hi Tony, Can you queue this patch ? On Fri, Sep 9, 2011 at 7:34 PM, T Krishnamoorthy, Balaji balaj...@ti.com wrote: On Fri, Aug 12, 2011 at 8:43 PM, Buckley, Bryan bryan.buck...@ti.com wrote: On Fri, Jul 22, 2011 at 7:30 AM, Kishore Kadiyala kishorek.kadiy...@gmail.com wrote: On Fri, Jul 22, 2011 at 12:59 AM, Bryan Buckley bryan.buck...@ti.com wrote: Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance with the control module programming guide. This fixes a bug where if trying to use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be affected by a changing SDMMC1_VDDS. Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever SDMMC1_VDDS ramps up/down or changes for cell protection purposes. MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore they can operate independently. Signed-off-by: Bryan Buckley bryan.buck...@ti.com Good catch, Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com Any other comments from anyone else? Noticed that this commit isn't in any upstream branches. This patch will fix issues with people who want to use GPIO 98/99 AND MMC1 at the same time. Would be good to have this fix upstream. FWIW: Tested on OMAP4 Blaze Tested-by: Balaji T K balaj...@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: [RFC PATCH 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
On Fri, Sep 16, 2011 at 7:43 PM, Greg KH gre...@suse.de wrote: On Fri, Sep 16, 2011 at 07:21:41PM +0530, ABRAHAM, KISHON VIJAY wrote: Sergei, Thanks for your comments. On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov sshtyl...@mvista.com wrote: Hello. On 15-09-2011 18:19, Kishon Vijay Abraham I wrote: Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting in incorrect detection of charger type. Hence OTG_INTERFSEL is configured to ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or USB_EVENT_VBUS notification. Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com Signed-off-by: Balaji T Kbalaj...@ti.com AFAIK, full name is needed here. is it not the prerogative of the person giving his signed-off by?? Not really. Certainly did not want to compete for long names :-) But Is Real Name + unique email id not sufficient. patches with this Signed-off . -- Thanks and Regards, Balaji T K -- 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] OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
On Fri, Aug 12, 2011 at 8:43 PM, Buckley, Bryan bryan.buck...@ti.com wrote: On Fri, Jul 22, 2011 at 7:30 AM, Kishore Kadiyala kishorek.kadiy...@gmail.com wrote: On Fri, Jul 22, 2011 at 12:59 AM, Bryan Buckley bryan.buck...@ti.com wrote: Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance with the control module programming guide. This fixes a bug where if trying to use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be affected by a changing SDMMC1_VDDS. Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever SDMMC1_VDDS ramps up/down or changes for cell protection purposes. MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore they can operate independently. Signed-off-by: Bryan Buckley bryan.buck...@ti.com Good catch, Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com Any other comments from anyone else? Noticed that this commit isn't in any upstream branches. This patch will fix issues with people who want to use GPIO 98/99 AND MMC1 at the same time. Would be good to have this fix upstream. FWIW: Tested on OMAP4 Blaze Tested-by: Balaji T K balaj...@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 5/5] OMAP: I2C: Restore only if context is lost
On Thu, Jul 21, 2011 at 12:23 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
Currently restore is done always.
Adding conditional restore.The restore is done only if the context is lost.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
@@ -261,6 +263,18 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
(i2c_dev-regs[reg] i2c_dev-reg_shift));
}
+
spurious line
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+}
+
static void omap_i2c_unidle(struct omap_i2c_dev *dev)
{
struct platform_device *pdev;
@@ -274,14 +288,11 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
pm_runtime_get_sync(pdev-dev);
if (pdata-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
- omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ u32 loss_cnt = omap_device_get_context_loss_count(pdev);
+ if (dev-dev_lost_count != loss_cnt)
+ omap_i2c_restore(dev);
}
+
dev-idle = 0;
/*
@@ -318,7 +329,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
}
dev-idle = 1;
-
+ dev-dev_lost_count = omap_device_get_context_loss_count(pdev);
pm_runtime_put_sync(pdev-dev);
}
@@ -574,6 +585,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
r = dev-device_reset(dev-dev);
if (r 0)
dev_err(dev-dev, reset failed\n);
+ omap_i2c_restore(dev);
}
omap_i2c_init(dev);
Are you sure you need both omap_i2c_restore, omap_i2c_init calls here ?
return -ETIMEDOUT;
@@ -589,6 +601,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
r = dev-device_reset(dev-dev);
if (r 0)
dev_err(dev-dev, reset failed\n);
+ omap_i2c_restore(dev);
same comment here
}
omap_i2c_init(dev);
return -EIO;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] OMAP: I2C: Remove the reset in the init path
On Thu, Jul 21, 2011 at 12:23 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
The reset in the driver at init is not needed
anymore as the hwmod framework takes care of
reseting it.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 57
+++--
1 files changed, 15 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 8f87a37..d6ea7de 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -155,9 +155,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_O (1 0) /* SDA line drive out
*/
#endif
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK (1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK (0x3 8)
#define SYSC_SIDLEMODE_MASK (0x3 3)
@@ -182,6 +179,8 @@ struct omap_i2c_dev {
u32 latency; /* maximum mpu wkup latency */
void (*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*device_reset)(struct device *dev);
+
u32 speed; /* Speed of bus in Khz */
u16 cmd_err;
u8 *buf;
@@ -332,7 +331,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
- unsigned long timeout;
unsigned long internal_clk = 0;
struct clk *fclk;
struct platform_device *pdev;
@@ -341,43 +339,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
pdev = to_platform_device(dev-dev);
pdata = pdev-dev.platform_data;
- if (dev-rev = OMAP_I2C_OMAP1_REV_2) {
- /* Disable I2C controller before soft reset */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
- omap_i2c_read_reg(dev, OMAP_I2C_CON_REG)
- ~(OMAP_I2C_CON_EN));
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_SOFTRESET_MASK);
- /* For some reason we need to set the EN bit before the
- * reset done bit gets set. */
- timeout = jiffies + OMAP_I2C_TIMEOUT;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- while (!(omap_i2c_read_reg(dev, OMAP_I2C_SYSS_REG)
- SYSS_RESETDONE_MASK)) {
- if (time_after(jiffies, timeout)) {
- dev_warn(dev-dev, timeout waiting
- for controller reset\n);
- return -ETIMEDOUT;
- }
- msleep(1);
- }
-
- /* SYSC register is cleared by the reset; rewrite it */
- if (dev-rev == OMAP_I2C_REV_ON_2430) {
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- SYSC_AUTOIDLE_MASK);
-
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
- dev-syscstate = SYSC_AUTOIDLE_MASK;
- dev-syscstate |= SYSC_ENAWAKEUP_MASK;
- dev-syscstate |= (SYSC_IDLEMODE_SMART
- __ffs(SYSC_SIDLEMODE_MASK));
- dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
- __ffs(SYSC_CLOCKACTIVITY_MASK));
-
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
- dev-syscstate);
+ if (dev-rev = OMAP_I2C_REV_ON_3430) {
/*
* Enabling all wakup sources to stop I2C freezing on
* WFI instruction.
one extra level of indentation
@@ -388,7 +350,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
dev-westate);
}
same
- }
+
spurious change, This comment applies to other patches in the series.
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (pdata-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
--
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: [PATCHv3 0/3] OMAP: HSMMC: cleanup and runtime pm
On Fri, Jul 1, 2011 at 1:06 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Balaji, On 6/30/2011 9:04 PM, Krishnamoorthy, Balaji T wrote: Removing the custom state machine - lazy disable framework in omap_hsmmc to make way for runtime pm to handle host controller power states. This allows mmc_host_enable/mmc_host_disable to be replaced by runtime get_sync and put_sync at host controller driver. Enable runtime PM in omap_hsmmc Rebased to 3.0-rc5 Tested on OMAP4430SDP, OMAP3430SDP, OMAP2430SDP MMC runtime patch has dependency on [PATCH 0/6] OMAP2+: hwmod framework fixes [1] for MMC1/MMC2 clock to get ungated after idle in OMAP4. Without [1] patches, MMC1/MMC2 fails to get detected on OMAP4. Mmm, that's weird, which one exactly is fixing the issue? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51458.html [PATCH 1/6] OMAP2+: hwmod: Fix smart-standby + wakeup support http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51461.html [PATCH 2/6] OMAP4: hwmod data: Add MSTANDBY_SMART_WKUP flag BTW, what is the issue exactly? with SIDLE_SMART_WKUP flag set in omap44xx_mmc_sysc, module got stuck after second clock enable. It got resolved after adding MSTANDBY_SMART_WKUP fixes . Removing SIDLE_SMART_WKUP also solves the issue.. Benoit [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51457.html Balaji T K (3): MMC: OMAP: HSMMC: Remove lazy_disable MMC: OMAP: HSMMC: add runtime pm support MMC: OMAP: HSMMC: Remove unused iclk drivers/mmc/host/omap_hsmmc.c | 365 +++-- 1 files changed, 57 insertions(+), 308 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
Re: [PATCHv3 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Fri, Jul 1, 2011 at 4:53 AM, Kevin Hilman khil...@ti.com wrote:
Balaji T K balaj...@ti.com writes:
+static int omap_hsmmc_runtime_resume(struct device *dev)
+{
+ struct omap_hsmmc_host *host;
+
+ host = platform_get_drvdata(to_platform_device(dev));
+ omap_hsmmc_context_restore(host);
+ dev_dbg(mmc_dev(host-mmc), host: enabled\n);
Minor: this has a 'host: ' prefix, where as the one in
.runtime_suspend() does not.
Fixing it in V4
+
+ return 0;
+}
+
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: [PATCHv2 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Thu, Jun 30, 2011 at 10:01 AM, T Krishnamoorthy, Balaji balaj...@ti.com wrote: On Wed, Jun 29, 2011 at 11:26 PM, Kevin Hilman khil...@ti.com wrote: T Krishnamoorthy, Balaji balaj...@ti.com writes: On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote: +Rajendra Balaji T K balaj...@ti.com writes: add runtime pm support to HSMMC host controller Use runtime pm API to enable/disable HSMMC clock Use runtime autosuspend APIs to enable auto suspend delay Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala Signed-off-by: Balaji T K balaj...@ti.com I tried to test this series along with Benoit's clkdm/modulemode/hwmod cleanups and something strange is happening on OMAP4. First, this series by itself is working as I would expect, but testing in combination with Benoit's series, it's different... First, I'm using Benoit's branch: git://gitorious.org/omap-pm/linux.git for_3.0.1/7_hwmod_modulemode in combination with your series. I've also reverted these two commits: OMAP4: PM: TEMP: Prevent l3init from idling/force sleep OMAP3+: hwmod data: TEMP: Do not idle MMC1 MMC2 after boot which are temporary workarounds for not having MMC runtime PM. I turned the dev_dbg calls in the runtime PM callbacks into dev_info callbacks to see exactly when the device is enabled/disabled via runtime PM. To my surprise, I didn't see the device being enabled/disabled when writing do the device. I tried for_3.0.1/7_hwmod_modulemode as you mentioned above, changing dev_dbg to dev_err and I am not observing the delayed write during umount. Can you let me know if the files are there in MMC after remounting ? Did you also revert the above two commits? yes I've pushed a 'tmp/mmc' branch to my git tree[1] which is my PM branch (including various PM stuff queued for upstream) as well as Benoit's series with the TEMP patches above reverted and your series on top of it. There's one additional patch to convert the dev_dbg into dev_info to see the transitions. Testing this on my OMAP4430 ES2.2 EMU device, I still see the above behavior. I used OMAP4430 ES2.1 GP Can you try out this branch on your board using the default omap2plus_defconfig? Ok, I will retry on EMU device. Tried on ES2.1 EMU, log shared at http://pastebin.com/Umg2zF2J Can you share your complete log? Thanks, Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.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: [PATCHv2 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote: +Rajendra Balaji T K balaj...@ti.com writes: add runtime pm support to HSMMC host controller Use runtime pm API to enable/disable HSMMC clock Use runtime autosuspend APIs to enable auto suspend delay Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala Signed-off-by: Balaji T K balaj...@ti.com I tried to test this series along with Benoit's clkdm/modulemode/hwmod cleanups and something strange is happening on OMAP4. First, this series by itself is working as I would expect, but testing in combination with Benoit's series, it's different... First, I'm using Benoit's branch: git://gitorious.org/omap-pm/linux.git for_3.0.1/7_hwmod_modulemode in combination with your series. I've also reverted these two commits: OMAP4: PM: TEMP: Prevent l3init from idling/force sleep OMAP3+: hwmod data: TEMP: Do not idle MMC1 MMC2 after boot which are temporary workarounds for not having MMC runtime PM. I turned the dev_dbg calls in the runtime PM callbacks into dev_info callbacks to see exactly when the device is enabled/disabled via runtime PM. To my surprise, I didn't see the device being enabled/disabled when writing do the device. I tried for_3.0.1/7_hwmod_modulemode as you mentioned above, changing dev_dbg to dev_err and I am not observing the delayed write during umount. Can you let me know if the files are there in MMC after remounting ? Any ideas why the same isn't happening when used with Benoit's series? Kevin P.S. note that the debug messages don't quite match. One says 'host: enabled' the other says 'disabled' (without the host: prefix.) making the prefixes match would be more readable. Ok, Will align dev_dbg prints. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote: On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 22 Jun 2011, Balaji T K wrote: Use runtime autosuspend APIs to enable auto suspend delay Does this really need to use runtime autosuspend? Seems to me that since PM runtime is just controlling the MMC IP blocks and not the regulators in this instance, this could simply use pm_runtime_put*() and just avoid the extra power wastage and complexity involved in autosuspend. I have seen some instabilities if delay is very less, on some production boards. Could you be more specific? What type of instabilities did you see? There have been some experiments on our customer programs to reduce this value to a few ms and infrequent crashes were observed (stress testing for several hours) while trying to access the controller registers. The previous implementation used 100ms delay before disabling the clocks. Is there any specific issue I should be aware of, for using _autosuspend ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman khil...@ti.com wrote: T Krishnamoorthy, Balaji balaj...@ti.com writes: On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote: (cc'ing Adrian also) Hi Balaji On Wed, 22 Jun 2011, Balaji T K wrote: Use runtime autosuspend APIs to enable auto suspend delay Does this really need to use runtime autosuspend? Seems to me that since PM runtime is just controlling the MMC IP blocks and not the regulators in this instance, this could simply use pm_runtime_put*() and just avoid the extra power wastage and complexity involved in autosuspend. I have seen some instabilities if delay is very less, on some production boards. The previous implementation used 100ms delay before disabling the clocks. And your new one is using 50ms. How did this value come about? I don't have any specific affinity to this number, but when requests are bursty, they arrive within a few 10s of ms within each other. Didn't want to have the context/save restore penalty associated with every request. As Paul mentioned, the timeout value here is probably usecase depeend There is no direct relationship to the use case. Block layer buffers and reworks the order of requests and they are usually queued together. Having no context save / restore penalty for each request is definitely desirable. (As I understand, MMC can lose context independent of MPU on OMAP4). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Wed, Jun 29, 2011 at 8:12 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote: On Wed, Jun 29, 2011 at 12:11 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 28 Jun 2011, T Krishnamoorthy, Balaji wrote: On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote: On Wed, 22 Jun 2011, Balaji T K wrote: Use runtime autosuspend APIs to enable auto suspend delay Does this really need to use runtime autosuspend? Seems to me that since PM runtime is just controlling the MMC IP blocks and not the regulators in this instance, this could simply use pm_runtime_put*() and just avoid the extra power wastage and complexity involved in autosuspend. I have seen some instabilities if delay is very less, on some production boards. Could you be more specific? What type of instabilities did you see? There have been some experiments on our customer programs to reduce this value to a few ms and infrequent crashes were observed (stress testing for several hours) while trying to access the controller registers. Was there an oops? Any analysis, etc.? OOPS pointed to omap_hsmmc_prepare_data / set_data_timeout Use case was MMC + SDIO +GPS activity, on kernel 2.6.35 though. Unhandled fault: imprecise external abort (0x1406) at 0x4073102c Internal error: : 1406 [#1] PREEMPT SMP last sysfs file: /sys/devices/platform/switch-sio/usb_sel Modules linked in: param(P) j4fs(P) vibetonz Si4709_driver fm_drv(C) bt_drv(C) st_drv(C) CPU: 0Tainted: PWC (2.6.35.7 #2) PC is at clk_get_rate+0x4/0x48 LR is at set_data_timeout+0x68/0xf4 [c06e78e0] (set_data_timeout+0x0/0xf4) from [c06e7dc8] (omap_hsmmc_request+0x2d0/0x5c8) r8:efa78400 r7:0001 r6: r5:ef9efe78 r4:efa78640 r3:ef9efee4 [c06e7af8] (omap_hsmmc_request+0x0/0x5c8) from [c06df040] (mmc_wait_for_req+0x118/0x130) [c06def28] (mmc_wait_for_req+0x0/0x130) from [c06e59e8] (mmc_blk_issue_rq+0x1c0/0x500) r6:ef86f000 r5:efa79000 r4:c91e61a0 [c06e5828] (mmc_blk_issue_rq+0x0/0x500) from [c06e6620] (mmc_queue_thread+0xf4/0xf8) [c06e652c] (mmc_queue_thread+0x0/0xf8) from [c045ddec] (kthread+0x84/0x8c) [c045dd68] (kthread+0x0/0x8c) from [c044b748] (do_exit+0x0/0x604) r7:0013 r6:c044b748 r5:c045dd68 r4:ef8d5d68 Code: e1a4 e89da8f0 c0a653c0 e1a0c00d (e92dd818) ---[ end trace 533b4c955f5abafd ]--- - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Wed, Jun 29, 2011 at 11:26 PM, Kevin Hilman khil...@ti.com wrote: T Krishnamoorthy, Balaji balaj...@ti.com writes: On Wed, Jun 29, 2011 at 5:02 AM, Kevin Hilman khil...@ti.com wrote: +Rajendra Balaji T K balaj...@ti.com writes: add runtime pm support to HSMMC host controller Use runtime pm API to enable/disable HSMMC clock Use runtime autosuspend APIs to enable auto suspend delay Based on OMAP HSMMC runtime implementation by Kevin Hilman, Kishore Kadiyala Signed-off-by: Balaji T K balaj...@ti.com I tried to test this series along with Benoit's clkdm/modulemode/hwmod cleanups and something strange is happening on OMAP4. First, this series by itself is working as I would expect, but testing in combination with Benoit's series, it's different... First, I'm using Benoit's branch: git://gitorious.org/omap-pm/linux.git for_3.0.1/7_hwmod_modulemode in combination with your series. I've also reverted these two commits: OMAP4: PM: TEMP: Prevent l3init from idling/force sleep OMAP3+: hwmod data: TEMP: Do not idle MMC1 MMC2 after boot which are temporary workarounds for not having MMC runtime PM. I turned the dev_dbg calls in the runtime PM callbacks into dev_info callbacks to see exactly when the device is enabled/disabled via runtime PM. To my surprise, I didn't see the device being enabled/disabled when writing do the device. I tried for_3.0.1/7_hwmod_modulemode as you mentioned above, changing dev_dbg to dev_err and I am not observing the delayed write during umount. Can you let me know if the files are there in MMC after remounting ? Did you also revert the above two commits? yes I've pushed a 'tmp/mmc' branch to my git tree[1] which is my PM branch (including various PM stuff queued for upstream) as well as Benoit's series with the TEMP patches above reverted and your series on top of it. There's one additional patch to convert the dev_dbg into dev_info to see the transitions. Testing this on my OMAP4430 ES2.2 EMU device, I still see the above behavior. I used OMAP4430 ES2.1 GP Can you try out this branch on your board using the default omap2plus_defconfig? Ok, I will retry on EMU device. Thanks, Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.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 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley p...@pwsan.com wrote: (cc'ing Adrian also) Hi Balaji On Wed, 22 Jun 2011, Balaji T K wrote: Use runtime autosuspend APIs to enable auto suspend delay Does this really need to use runtime autosuspend? Seems to me that since PM runtime is just controlling the MMC IP blocks and not the regulators in this instance, this could simply use pm_runtime_put*() and just avoid the extra power wastage and complexity involved in autosuspend. I have seen some instabilities if delay is very less, on some production boards. The previous implementation used 100ms delay before disabling the clocks. Is there any specific issue I should be aware of, for using _autosuspend ? Besides, the correct autosuspend timeout seems use-case dependent. By the way, if possible, it would be really good if you could update this patch series soon to address the comments. If these MMC driver changes can be ready to merge for 3.1, then we also have a chance of integrating some hwmod cleanup patches that depend on this driver's PM runtime conversion. Just noticed your mail after I posted my patches.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] MMC: OMAP: HSMMC: Remove unused iclk
On Wed, Jun 22, 2011 at 9:57 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 6/22/2011 4:18 PM, Krishnamoorthy, Balaji T wrote:
After runtime conversion to handle clk,
iclk node is not used
However fclk node is still used to get clock rate.
Signed-off-by: Balaji T Kbalaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5b81d8b..afcca36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -145,7 +145,6 @@ struct omap_hsmmc_host {
struct mmc_command *cmd;
struct mmc_data *data;
struct clk *fclk;
- struct clk *iclk;
struct clk *dbclk;
/*
* vcc == configured supply
@@ -1855,17 +1854,10 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
spin_lock_init(host-irq_lock);
- host-iclk = clk_get(pdev-dev, ick);
- if (IS_ERR(host-iclk)) {
- ret = PTR_ERR(host-iclk);
- host-iclk = NULL;
- goto err1;
- }
host-fclk = clk_get(pdev-dev, fck);
if (IS_ERR(host-fclk)) {
ret = PTR_ERR(host-fclk);
host-fclk = NULL;
- clk_put(host-iclk);
goto err1;
}
@@ -2025,7 +2017,6 @@ err_irq:
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
clk_put(host-fclk);
Since you just have to use the clk_get_rate, you can remove as well all the
clock related functions for the fck node: clk_put / clk_enable...
clk_enable is removed, but would prefer to keep clk_put for balancing clk_get
- clk_put(host-iclk);
if (host-got_dbclk) {
clk_disable(host-dbclk);
clk_put(host-dbclk);
@@ -2062,7 +2053,6 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
pm_runtime_forbid(host-dev);
pm_runtime_disable(host-dev);
clk_put(host-fclk);
Here as well.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] MMC: OMAP: HSMMC: add runtime pm support
On Thu, Jun 23, 2011 at 12:08 AM, Kevin Hilman khil...@ti.com wrote:
Balaji T K balaj...@ti.com writes:
@@ -1880,18 +1873,12 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
mmc-caps |= MMC_CAP_DISABLE;
- if (clk_enable(host-iclk) != 0) {
- clk_put(host-iclk);
- clk_put(host-fclk);
- goto err1;
- }
-
- if (mmc_host_enable(host-mmc) != 0) {
- clk_disable(host-iclk);
- clk_put(host-iclk);
- clk_put(host-fclk);
- goto err1;
- }
+ pm_runtime_enable(host-dev);
+ pm_runtime_allow(host-dev);
+ pm_runtime_get_sync(host-dev);
+ pm_runtime_set_autosuspend_delay(host-dev, MMC_AUTOSUSPEND_DELAY);
+ pm_runtime_use_autosuspend(host-dev);
+ pm_suspend_ignore_children(host-dev, 1);
Why is ignore_children needed for this device? Is this device the
parent of other devices? If it is, why should it ignore it's
children?
No, I will remove. Added it for testing only.
if (cpu_is_omap2430()) {
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
@@ -2018,6 +2005,8 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
}
omap_hsmmc_debugfs(mmc);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
return 0;
@@ -2033,8 +2022,8 @@ err_reg:
err_irq_cd_init:
free_irq(host-irq, host);
err_irq:
- mmc_host_disable(host-mmc);
- clk_disable(host-iclk);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
clk_put(host-fclk);
clk_put(host-iclk);
if (host-got_dbclk) {
@@ -2058,7 +2047,7 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
struct resource *res;
if (host) {
- mmc_host_enable(host-mmc);
+ pm_runtime_get_sync(host-dev);
mmc_remove_host(host-mmc);
if (host-use_reg)
omap_hsmmc_reg_put(host);
@@ -2069,8 +2058,9 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
free_irq(mmc_slot(host).card_detect_irq, host);
flush_work_sync(host-mmc_carddetect_work);
- mmc_host_disable(host-mmc);
- clk_disable(host-iclk);
+ pm_runtime_put_sync(host-dev);
+ pm_runtime_forbid(host-dev);
Why?
Added for balancing pm_runtime_allow added in _probe.
But forbid also resume the device on remove.
Should this be removed, keeping _allow in _probe ?
+ pm_runtime_disable(host-dev);
clk_put(host-fclk);
clk_put(host-iclk);
if (host-got_dbclk) {
@@ -2102,6 +2092,8 @@ static int omap_hsmmc_suspend(struct device *dev)
return 0;
if (host) {
+ /* FIXME: TODO move get_sync to proper dev_pm_ops function */
what does this mean?
get_sync is needed to enable clock before accessing the registers but
the discusssion @
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg50819.html
suggested to move runtime get_sync calls to .prepare
Haven't tried it yet.
+ pm_runtime_get_sync(host-dev);
host-suspended = 1;
if (host-pdata-suspend) {
ret = host-pdata-suspend(pdev-dev,
@@ -2116,13 +2108,11 @@ static int omap_hsmmc_suspend(struct device *dev)
}
cancel_work_sync(host-mmc_carddetect_work);
ret = mmc_suspend_host(host-mmc);
- mmc_host_enable(host-mmc);
+
if (ret == 0) {
omap_hsmmc_disable_irq(host);
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
- mmc_host_disable(host-mmc);
- clk_disable(host-iclk);
if (host-got_dbclk)
clk_disable(host-dbclk);
} else {
@@ -2134,8 +2124,9 @@ static int omap_hsmmc_suspend(struct device *dev)
dev_dbg(mmc_dev(host-mmc),
Unmask interrupt failed\n);
}
- mmc_host_disable(host-mmc);
}
+ /* FIXME: TODO move put_sync to proper dev_pm_ops function */
ditto
+ pm_runtime_put_sync(host-dev);
}
return ret;
@@ -2152,14 +2143,8 @@ static int omap_hsmmc_resume(struct device *dev)
return 0;
if (host) {
- ret = clk_enable(host-iclk);
- if (ret)
- goto clk_en_err;
-
- if (mmc_host_enable(host-mmc) != 0) {
- clk_disable(host-iclk);
- goto clk_en_err;
- }
+ /* FIXME: TODO move put_sync to proper dev_pm_ops function */
Re: [PATCH 1/3] MMC: OMAP: HSMMC: Remove lazy_disable
On Wed, Jun 22, 2011 at 11:56 PM, Kevin Hilman khil...@ti.com wrote: Balaji T K balaj...@ti.com writes: lazy_disable framework in OMAP HSMMC manages multiple low power states and Card is powered off after inactivity time of 8 seconds. Based on previous discussion on the list Card power(regulator) needs some punctuation for readability. OK handling (when to power OFF/ON) should ideally be handled by core layer. So are you working on the core layer replacement for this? If not, is there a plan or owner for this? Venkat and myself are planing to start on this for MMC and SD. Some partial work has already been done for SDIO, need to consolidate this for all three of them. Remove usage of lazy disable to allow core layer _only_ to handle card power. With the removal of lazy disable framework, MMC regulators are left ON until MMC_POWER_OFF via set_ios. Signed-off-by: Balaji T K balaj...@ti.com [...] @@ -2080,10 +1848,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, host); INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect); - if (mmc_slot(host).power_saving) - mmc-ops = omap_hsmmc_ps_ops; - else - mmc-ops = omap_hsmmc_ops; + mmc-ops = omap_hsmmc_ops; I guess the _ps_ops struct is now completely unused so should probably be removed in this patch also. done -- 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] OMAP4 :TWL6030: Regulator set the default behavior of LDO's
On Wed, Jun 22, 2011 at 5:54 AM, Girish S G giris...@ti.com wrote:
TWL6030 below table shows the default state each LDO's can
be put into.
+---+
| LDO | Usage | state |
+---+
| VANA | sources internal | Always ON |
| | analog voltage | |
+---+
| VAUX1 | eMMC | MMC Driver needs to handle |
| | | |
+---+
| VAUX2 | A/V switch | Driver needs to handle |
+---+
| VAUX3 | 5MP CAMp | Driver needs to handle |
+---+
| VCXIO | supplies DPLL's | Can be put OFF when OMAP hits |
| | | OFF mode. |
+---+
| VDAC | HDMI, CDC chip | Always ON |
+---+
| VMMC | MMC | Driver needs to handle |
+---+
| VPP | VPP pins of OMAP | Used while burning fuses in |
| | | OMAP. This can be turned OFF |
| | | by default when kernel comes |
| | | up. |
+---+
| VRTC | VBRTC/RTC | Always ON |
+---+
| VUSB | USB OTG pins | Driver needs to handle |
+---+
| VUSIM | VDDS_SIM, SIM cage | Driver needs to handle. |
+---+
| CLK32K| 32KHz o/p clk | WIFI/BT/FM/GPS driver needs |
| | | to handle |
+---+
- VDAC, VANA, VCXIO and VRTC should be kept always ON. As per the table
above.
Need REVISIT on below LDO's:
- VAUX1 kept ON now. MMC driver needs to take care of enabling/disabling
as needed. Issue seen with eMMC bootup with VAUX1 disabled by default.
- VAUX3 is kept ON now. CAM/syslink should handle this regulator. This
is only for 5MP camera on Blaze.
- CLK32KG is pseudo regulator, on Blaze/panda it supplies GPS/WIFI/BT/FM/GPS
Drivers should handle it. Keeping it always ON as of now.
description and code changes are not in sync.
vmmc, vana, vdac, vusb is kept as always_on.
Can you try boot_on if it fits you requirement.
--
Thanks and Regards,
Balaji T K
Signed-off-by: Girish S G giris...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 4
arch/arm/mach-omap2/board-omap4panda.c | 3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 63de2d3..04b7770 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -440,6 +440,7 @@ static struct regulator_init_data sdp4430_vmmc = {
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
.num_consumer_supplies = 1,
.consumer_supplies = sdp4430_vmmc_supply,
@@ -479,6 +480,7 @@ static struct regulator_init_data sdp4430_vana = {
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
};
@@ -501,6 +503,7 @@ static struct regulator_init_data sdp4430_vdac = {
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
};
@@ -519,6 +522,7 @@ static struct regulator_init_data sdp4430_vusb = {
static struct regulator_init_data sdp4430_clk32kg = {
.constraints = {
.valid_ops_mask
Re: [PATCH 1/2] ARM: OMAP4: MMC: increase delay for pbias
On Wed, Jun 1, 2011 at 1:11 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110530 07:23]:
4 micro seconds is not enough for PBIAS if MMC regulator is
enabled from MMC regulator OFF.
Increase the delay for PBIAS to stabilize.
Wait for PBIAS and timeout if not.
Resolves MMC/SD failure on OMAP4
Pbias Voltage is not same as LDO
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/hsmmc.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b2f30be..3f8dc16 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -145,6 +145,7 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
int power_on, int vdd)
{
u32 reg;
+ unsigned long timeout;
if (power_on) {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
@@ -157,9 +158,15 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
OMAP4_MMC1_PWRDNZ_MASK |
OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
- /* 4 microsec delay for comparator to generate an error*/
- udelay(4);
- reg = omap4_ctrl_pad_readl(control_pbias_offset);
+
+ timeout = jiffies + msecs_to_jiffies(5);
+ do {
+ reg = omap4_ctrl_pad_readl(control_pbias_offset);
+ if (!(reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK))
+ break;
+ udelay(100);
+ } while (!time_after(jiffies, timeout));
+
if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
/* Caution : On VMODE_ERROR Power Down MMC IO */
Actually, can you check if you can use usleep_range here as recommended
by checkpatch.pl?
sure, fixing it in v2
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] mfd: twl6040: Add initial support
On Wed, Jun 1, 2011 at 4:47 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
From: Misael Lopez Cruz misael.lo...@ti.com
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The audio modules are controlled by internal registers that
can be accessed by I2C and PDM interface.
TWL6040 MFD will be registered as a child of TWL-CORE, and will
have two children of its own: twl6040-codec and twl6040-vibra.
This driver is based on TWL4030 and WM8350 MFD drivers.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Margarita Olaya Cabrera magi.ol...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/include/plat/irqs.h | 12 +-
drivers/mfd/Kconfig | 6 +
drivers/mfd/Makefile | 1 +
drivers/mfd/twl-core.c | 5 +-
drivers/mfd/twl6040-core.c | 589
drivers/mfd/twl6040-irq.c | 205 +++
include/linux/i2c/twl.h | 1 +
include/linux/mfd/twl6040.h | 260 ++
8 files changed, 1074 insertions(+), 5 deletions(-)
create mode 100644 drivers/mfd/twl6040-core.c
create mode 100644 drivers/mfd/twl6040-irq.c
create mode 100644 include/linux/mfd/twl6040.h
diff --git a/arch/arm/plat-omap/include/plat/irqs.h
b/arch/arm/plat-omap/include/plat/irqs.h
index 5a25098..2cfba51 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -407,11 +407,19 @@
#endif
#define TWL6030_IRQ_END (TWL6030_IRQ_BASE +
TWL6030_BASE_NR_IRQS)
+#define TWL6040_CODEC_IRQ_BASE TWL6030_IRQ_END
+#ifdef CONFIG_TWL6040_CODEC
+#define TWL6040_CODEC_NR_IRQS 6
+#else
+#define TWL6040_CODEC_NR_IRQS 0
+#endif
+#define TWL6040_CODEC_IRQ_END (TWL6040_CODEC_IRQ_BASE +
TWL6040_CODEC_NR_IRQS)
+
/* Total number of interrupts depends on the enabled blocks above */
-#if (TWL4030_GPIO_IRQ_END TWL6030_IRQ_END)
+#if (TWL4030_GPIO_IRQ_END TWL6040_CODEC_IRQ_END)
#define TWL_IRQ_END TWL4030_GPIO_IRQ_END
#else
-#define TWL_IRQ_END TWL6030_IRQ_END
+#define TWL_IRQ_END TWL6040_CODEC_IRQ_END
#endif
/* GPMC related */
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a6f76a..ac6b4ae 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -233,6 +233,12 @@ config TWL6030_PWM
Say yes here if you want support for TWL6030 PWM.
This is used to control charging LED brightness.
+config TWL6040_CORE
+ bool
+ depends on TWL4030_CORE GENERIC_HARDIRQS
+ select MFD_CORE
+ default n
+
config MFD_STMPE
bool Support STMicroelectronics STMPE
depends on I2C=y GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4cf9465..41f3b61 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_TWL4030_POWER) += twl4030-power.o
obj-$(CONFIG_MFD_TWL4030_AUDIO) += twl4030-audio.o
obj-$(CONFIG_TWL6030_PWM) += twl6030-pwm.o
+obj-$(CONFIG_TWL6040_CORE) += twl6040-core.o twl6040-irq.o
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index f9d7880..a2eddc7 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -110,7 +110,7 @@
#endif
#if defined(CONFIG_TWL4030_CODEC) || defined(CONFIG_TWL4030_CODEC_MODULE) ||\
- defined(CONFIG_SND_SOC_TWL6040) ||
defined(CONFIG_SND_SOC_TWL6040_MODULE)
+ defined(CONFIG_TWL6040_CORE) || defined(CONFIG_TWL6040_CORE_MODULE)
#define twl_has_codec() true
#else
#define twl_has_codec() false
@@ -824,10 +824,9 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
return PTR_ERR(child);
}
- /* Phoenix codec driver is probed directly atm */
if (twl_has_codec() pdata-audio twl_class_is_6030()) {
sub_chip_id = twl_map[TWL_MODULE_AUDIO_VOICE].sid;
- child = add_child(sub_chip_id, twl6040-codec,
+ child = add_child(sub_chip_id, twl6040,
pdata-audio, sizeof(*pdata-audio),
false, 0, 0);
if (IS_ERR(child))
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
new file mode 100644
index 000..bb36862
--- /dev/null
+++ b/drivers/mfd/twl6040-core.c
@@ -0,0 +1,589 @@
+/*
+ * MFD driver for TWL6040 audio device
+ *
+ * Authors: Misael Lopez Cruz misael.lo...@ti.com
+ * Jorge
Re: V 3.0-rc1: [REPORT] OMAP MMC and CONSOLE Regression
On Mon, May 30, 2011 at 6:03 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
While trying out V3.0-rc1, I noticed couple of regressions. Am
posting this in case anybody come across same issues.
1.OMAP MMC code keep throwing Pbias Voltage is not same as LDO error
continuously.
Balaji is planning post right fix for the same, but just
in case you get around this issue,
Hi Santosh,
You can find MMC pbias fix here
http://www.spinics.net/lists/linux-omap/msg51735.html
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b2f30be..94ae400 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -145,6 +145,7 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
int power_on, int vdd)
{
u32 reg;
+ unsigned long timeout;
if (power_on) {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
@@ -158,7 +159,14 @@ static void omap4_hsmmc1_after_set_reg(struct device
*dev, int slot,
OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
/* 4 microsec delay for comparator to generate an error*/
- udelay(4);
+ timeout = jiffies + msecs_to_jiffies(500);
+ do {
+ reg = omap4_ctrl_pad_readl(control_pbias_offset);
+ if (!(reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK))
+ break;
+ mdelay(1);
+ } while (!time_after(jiffies, timeout));
+
reg = omap4_ctrl_pad_readl(control_pbias_offset);
if (reg OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
--
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] ARM: OMAP4: MMC: no regulator off during probe for eMMC
On Tue, May 31, 2011 at 6:56 PM, Tony Lindgren t...@atomide.com wrote:
* Balaji T K balaj...@ti.com [110530 07:23]:
eMMC does not handle power off when not in sleep state,
Skip regulator disable during probe when eMMC is
not in known state - state left by bootloader.
Resolves eMMC failure on OMAP4
mmc0: error -110 whilst initialising MMC card
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -18,6 +18,7 @@ struct omap2_hsmmc_info {
bool nonremovable; /* Nonremovable e.g. eMMC */
bool power_saving; /* Try to sleep or power off when possible */
bool no_off; /* power_saving and power is not to go off */
+ bool no_off_init; /* no power off when not in MMC sleep state */
bool vcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
int gpio_cd; /* or -EINVAL */
int gpio_wp; /* or -EINVAL */
Can't you use no_off for this too?
no_off is used for devices which do not want to disable regulator at any time.
newly introduced no_off_init is to skip disable regulator only during probe
After eMMC is put in sleep state (while suspend), regulator for eMMC
(VAUX1) can be disabled.
--
Thanks and Regards,
Balaji T K
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] REGULATOR: TWL6025: add support to twl-regulator
On Thu, May 19, 2011 at 12:02 AM, Graeme Gregory g...@slimlogic.co.uk wrote:
Adding support for the twl6025. Major difference in the twl6025 is the
group functionality has been removed from the chip so this affects how
regulators are enabled and disabled.
The names of the regulators also changed.
The DCDCs of the 6025 are software controllable as well.
Since V1
Use the features variable passed via platform data instead of calling
global function.
Change the very switch like if statements to be a more readable
switch statement.
Since V2
twl6025 doesn't use remap so remove it from the macros.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/twl-regulator.c | 410 +---
1 files changed, 375 insertions(+), 35 deletions(-)
snip
+
+static int twl6030dcdc_list_voltage(struct regulator_dev *rdev, unsigned
index)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+
+ int voltage = 0;
+
+ switch (info-flags) {
+ case 0:
+ switch (index) {
+ case 0:
+ voltage = 0;
+ break;
+ case 58:
Not sure if hex 0x3A is better here, TRM gives in binary though.
+ voltage = 1350 * 1000;
+ break;
+ case 59:
+ voltage = 1500 * 1000;
+ break;
+ case 60:
+ voltage = 1800 * 1000;
+ break;
+ case 61:
+ voltage = 1900 * 1000;
+ break;
+ case 62:
+ voltage = 2100 * 1000;
+ break;
+ default:
+ voltage = (60 + (12500 * (index - 1)));
+ }
+ break;
+ case DCDC_OFFSET_EN:
+ switch (index) {
+ case 0:
+ voltage = 0;
+ break;
+ case 58:
+ voltage = 1350 * 1000;
+ break;
+ case 59:
+ voltage = 1500 * 1000;
+ break;
+ case 60:
+ voltage = 1800 * 1000;
+ break;
+ case 61:
+ voltage = 1900 * 1000;
+ break;
+ case 62:
+ voltage = 2100 * 1000;
+ break;
+ default:
+ voltage = (70 + (12500 * (index - 1)));
Between DCDC_OFFSET_EN and case 0
70 and 60 is the only difference,
can it be handled via additional 10 in case DCDC_OFFSET_EN?
like
+ case DCDC_OFFSET_EN:
voltage = 10;
/* fall through */
+ case 0:
voltage += (60 + (12500 * (index - 1)));
+ }
+ break;
+ case DCDC_EXTENDED_EN:
+ switch (index) {
+ case 0:
+ voltage = 0;
+ break;
+ case 58:
+ voltage = 2084 * 1000;
+ break;
+ case 59:
+ voltage = 2315 * 1000;
+ break;
+ case 60:
+ voltage = 2778 * 1000;
+ break;
+ case 61:
+ voltage = 2932 * 1000;
+ break;
+ case 62:
+ voltage = 3241 * 1000;
+ break;
+ default:
+ voltage = (1852000 + (38600 * (index - 1)));
+ }
+ break;
+ case DCDC_OFFSET_EN|DCDC_EXTENDED_EN:
space between |
+ switch (index) {
+
+static int
+twl6030dcdc_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV,
+ unsigned int *selector)
+{
+ struct twlreg_info *info = rdev_get_drvdata(rdev);
+ int vsel = 0;
+
+ switch (info-flags) {
+ case 0:
+ if (min_uV == 0)
+ vsel = 0;
+ else if ((min_uV = 60) (max_uV = 130)) {
+ vsel = (min_uV - 60) / 125;
+ if (vsel % 100)
+ vsel += 100;
+ vsel /= 100;
+ vsel++;
+ }
+ /* Values 1..57 for vsel are linear and can be calculated
+* values 58..62 are non linear.
+*/
+ else if ((min_uV 190) (max_uV = 210))
+ vsel = 62;
+ else if ((min_uV 180) (max_uV = 190))
+ vsel = 61;
+
Re: [PATCH v2 3/4] REGULATOR: TWL6025: add support to twl-regulator
On Thu, May 12, 2011 at 6:57 PM, Graeme Gregory g...@slimlogic.co.uk wrote:
Adding support for the twl6025. Major difference in the twl6025 is the
group functionality has been removed from the chip so this affects how
regulators are enabled and disabled.
The names of the regulators also changed.
The DCDCs of the 6025 are software controllable as well.
Since V1
Use the features variable passed via platform data instead of calling
global function.
Change the very switch like if statements to be a more readable
switch statement.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/twl-regulator.c | 414 +---
1 files changed, 379 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 2a808c2..51f28cc 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -51,8 +51,13 @@ struct twlreg_info {
u16 min_mV;
u16 max_mV;
+ u8 flags;
+
/* used by regulator core */
struct regulator_desc desc;
+
+ /* chip specific features */
+ unsigned long features;
};
@@ -70,6 +75,7 @@ struct twlreg_info {
#define VREG_TRANS 1
#define VREG_STATE 2
#define VREG_VOLTAGE 3
+#define VREG_VOLTAGE_DCDC 4
/* TWL6030 Misc register offsets */
#define VREG_BC_ALL1
#define VREG_BC_REF2
@@ -87,6 +93,17 @@ struct twlreg_info {
#define TWL6030_CFG_STATE_APP(v) (((v) TWL6030_CFG_STATE_APP_MASK)
\
TWL6030_CFG_STATE_APP_SHIFT)
+/* Flags for DCDC Voltage reading */
+#define DCDC_OFFSET_EN BIT(0)
+#define DCDC_EXTENDED_EN BIT(1)
+
+/* twl6025 SMPS EPROM values */
+#define TWL6030_SMPS_OFFSET0xB0
+#define TWL6030_SMPS_MULT 0xB3
+#define SMPS_MULTOFFSET_SMPS4 BIT(0)
+#define SMPS_MULTOFFSET_VIOBIT(1)
+#define SMPS_MULTOFFSET_SMPS3 BIT(6)
+
static inline int
twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned offset)
{
@@ -144,11 +161,15 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp, val;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(info-features TWL6025_SUBCLASS)) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- grp = P1_GRP_6030;
+ grp = P1_GRP_6030;
+ } else {
+ grp = 1;
+ }
val = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_STATE);
val = TWL6030_CFG_STATE_APP(val);
@@ -159,19 +180,22 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
static int twlreg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
+ int grp = 0;
+ int ret = 0;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(twl_class_is_6030() (info-features TWL6025_SUBCLASS))) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- if (twl_class_is_4030())
- grp |= P1_GRP_4030;
- else
- grp |= P1_GRP_6030;
+ if (twl_class_is_4030())
+ grp |= P1_GRP_4030;
+ else
+ grp |= P1_GRP_6030;
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER,
+ VREG_GRP, grp);
+ }
if (!ret twl_class_is_6030())
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
@@ -186,29 +210,34 @@ static int twlreg_enable(struct regulator_dev *rdev)
static int twlreg_disable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
-
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
-
- /* For 6030, set the off state for all grps enabled */
- if (twl_class_is_6030()) {
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
- (grp (P1_GRP_6030 | P2_GRP_6030 | P3_GRP_6030))
- TWL6030_CFG_STATE_GRP_SHIFT |
-
