RE: [PATCH] OMAP3:devices.c: Enabling 4-bit for SD card
Tony,
I updated patch for MMC1 and MMC2 and also refreshed the patch.
I am attaching patch with this mail.
Regards,
Purushotam
-Original Message-
From: Kumar, Purushotam
Sent: Wednesday, June 25, 2008 3:34 PM
To: Tony Lindgren; Purushotam Kumar
Cc: linux-omap@vger.kernel.org; Gole, Anant
Subject: RE: [PATCH] OMAP3:devices.c: Enabling 4-bit for SD card
-Original Message-
From: Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: Monday, June 23, 2008 6:17 PM
To: Purushotam Kumar
Cc: linux-omap@vger.kernel.org; Gole, Anant
Subject: Re: [PATCH] OMAP3:devices.c: Enabling 4-bit for SD card
* Purushotam Kumar [EMAIL PROTECTED] [080616 16:03]:
OMAP3:devices.c:Enabling 4-bit for SD card
SD card was working in 1-bit mode.This patch will configure SD card in
4-bit mode and hence performance will increase.
Signed-off-by: Purushotam Kumar [EMAIL PROTECTED]
Acked-by: Madhusudhan Chikkature Rajashekar [EMAIL PROTECTED]
---
arch/arm/plat-omap/devices.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/plat-omap/devices.c
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/devices.c
+++ linux-omap-2.6/arch/arm/plat-omap/devices.c
@@ -292,8 +292,10 @@ static void __init omap_init_mmc(void)
mmc = mmc_conf-mmc[0];
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
- if (mmc-enabled)
+ if (mmc-enabled) {
+ mmc1_data.conf = *mmc;
(void) platform_device_register(mmc_omap_device1);
+ }
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
mmc = mmc_conf-mmc[1];
I guess this should be also done for mmc2_data.conf?
Tony
I agree with you that it is required to be done for MMC2 as well.
Please push this patch for MMC1 and I will submit other patch latter for MMC2.
Regards,
Purushotam
enable_sd_4bit.patch
Description: enable_sd_4bit.patch
RE: Kernel hang on OMAP3 based Beagle board, RTC issue?
Hi,
Hi,
ext Gadiyar, Anand [EMAIL PROTECTED] writes:
Hi All,
snip
Tried that and I get the same hang, so I don't think the RTC is to
blame.
Short update just in case anybody has an idea:
Gadiyar spent some time with git-bisect (thanks!):
It seems that the bad commit is probably between:
# good: [3ffec4e18484c34838fa341de3848306c29ecd5d] 24XX: PM: Move pm.c
to pm24xx.c
and sleep.S to sleep24xx.S
and # bad: [458776cfe389ff03bd6c56c47e059df0778cdfca] OMAP3430SDP:
Enable config options CONFIG_OMAP_RESET_CLOCKS and CONFIG_SUSPEND
This is a 9-patch series by Jouni Hogander related to suspend and
power-management.
Dirk
I'm still working on the git-bisect. I'm currently waiting for ten minutes
after boot before marking a commit good or bad. If the hang happens more
than ten minutes after boot, I might miss that and mark the commit good -
so
I will re-check the good commits one more time and confirm.
- Anand
As far as I can tell, the beagle hang issue aries after this commit:
397f49cde4e75cf662a23814097db35f3e6c6b62 is first bad commit
commit 397f49cde4e75cf662a23814097db35f3e6c6b62
Author: Jouni Hogander [EMAIL PROTECTED]
Date: Fri May 16 13:58:25 2008 +0300
34XX: PM: Initial version of suspend and dynamic retention
This is initial version of suspend and dynamic retention for
34xx. Omap is tried to put to full retention on suspend and pm_idle.
Signed-off-by: Jouni Hogander [EMAIL PROTECTED]
Signed-off-by: Tony Lindgren [EMAIL PROTECTED]
Could someone please test and confirm if the previous commit works without
a hang?
I waited for around 20 minutes and did not observe a hang.
These were the last two good commits I got from git-bisect.
# good: [1c66e10c850950a84da68cafb07022eab5e7eec0] 34XX: Suspend: Take
suspend sram code from ti cdp kernel
git-bisect good 1c66e10c850950a84da68cafb07022eab5e7eec0
# good: [131ce2d1dd5081f97885419678a8b3211c7c2dee] 34XX: Add miscellaneous
definitions related to 34xx
Unfortunately I have only sdp board here and I'm not able to reproduce
this with it. Are you using omap3_beagle_defconfig without
modifications there?
Yes.
You mentioned prcm interrupts in this thread. Are you normally seeing
them? I'm wondering this because you shouldn't see them with current
l-o tree and default beagle config. Are you enabling sleep_while_idle
(echo 1 /sys/power/sleep_while_idle)?
Haven't tried this. All we did was boot the board from MMC and leave it running
for around ten minutes.
You have end up to conclusion that 34XX: PM: Initial version of
suspend and dynamic retention is causing this? Could you try to apply
this on top of mentioned commit and see if you still can see that
hang:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 202c269..308835b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -380,11 +380,11 @@ int __init omap3_pm_init(void)
goto err1;
}
- ret = pwrdm_for_each(pwrdms_setup);
- if (ret) {
- printk(KERN_ERR Failed to setup powerdomains\n);
- goto err2;
- }
+/* ret = pwrdm_for_each(pwrdms_setup); */
+/* if (ret) { */
+/* printk(KERN_ERR Failed to setup powerdomains\n); */
+/* goto err2; */
+/* } */
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
With this change, the hang does not happene. Applied this patch on the current
linux-omap tree.
Thanks for the patch. It fixes the hang for now. I'm not sure why the hang
happens, but could it be because the SDP uses ttyS0 by default as the
console while the Beagle is on ttyS2?
Regards,
Anand
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH 04/09] OMAP PM srf implementation
Hi Rajendra,
+void omap_pm_set_min_bus_tput(struct device *dev, struct bus_type *bus,
+ unsigned long r)
According to Paul's prototypes this should be
void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id,
unsigned long r)
+{
+ if (!dev) {
+ WARN_ON(1);
+ return;
+ };
+
+ if (r == 0)
+ pr_debug(OMAP PM: remove min bus tput constraint:
+ dev %p for bus %s\n, dev, bus-name);
+ else
+ pr_debug(OMAP PM: add min bus tput constraint:
+ dev %p for bus %s: rate %ld KiB\n, dev,
+ bus-name, r);
+
+ /*
+ * This code should model the bus and compute the required
+ * bus frequency, convert that to a VDD2 OPP ID, then set the VDD2
+ * OPP appropriately.
+ *
+ * TI CDP code can call constraint_set here on the VDD2 OPP.
+ */
+}
+
omap_pm_if_early_init and omap_pm_if_init are missing. I added dummy
functions for those.
With all of these changes it seems to work.
Cheers,
Peter.
--
goa is a state of mind
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/09] OMAP PM srf implementation
Hi Peter,
-Original Message-
From: Peter 'p2' De Schrijver [mailto:[EMAIL PROTECTED]
Sent: Monday, July 14, 2008 6:59 PM
To: ext Rajendra Nayak
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 04/09] OMAP PM srf implementation
Hi Rajendra,
+void omap_pm_set_min_bus_tput(struct device *dev, struct
bus_type *bus,
+ unsigned long r)
According to Paul's prototypes this should be
void omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id,
unsigned long r)
+{
+ if (!dev) {
+ WARN_ON(1);
+ return;
+ };
+
+ if (r == 0)
+ pr_debug(OMAP PM: remove min bus tput constraint:
+dev %p for bus %s\n, dev, bus-name);
+ else
+ pr_debug(OMAP PM: add min bus tput constraint:
+dev %p for bus %s: rate %ld KiB\n, dev,
+bus-name, r);
+
+ /*
+* This code should model the bus and compute the required
+* bus frequency, convert that to a VDD2 OPP ID, then
set the VDD2
+* OPP appropriately.
+*
+* TI CDP code can call constraint_set here on the VDD2 OPP.
+*/
+}
+
omap_pm_if_early_init and omap_pm_if_init are missing. I added dummy
functions for those.
With all of these changes it seems to work.
Yes, I probably was using an older omap-pm-noop patch from Paul.
I did not refresh it since, the later one sent was again not the final one.
I though I would refresh it once the final version is posted.
Paul,
Would you be posting another version of this with changes as suggested
by Jouni?
Cheers,
Peter.
--
goa is a state of mind
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
