Re: am3517: geting MMC working
On Fri, Jul 20, 2012 at 10:01:09AM +0200, Yegor Yefremov wrote:
Am 20.07.2012 09:39, schrieb Yegor Yefremov:
Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji:
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.
This is Apacer 2GB. In 3.3-rc7 I have no problems with it. Should I enable
debugging in 3.3-rc7 and post the output?
I found the solution:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..0ab26ab 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -359,7 +359,7 @@ static void omap3_pm_idle(void)
{
local_fiq_disable();
- if (omap_irq_pending())
+ if (omap_irq_pending() || !omap3_has_io_wakeup())
goto out;
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
I've seen this hack for some on the mailing list. I think
Mark A. Greer introduced it, but I don't remember for sure.
Can this patch be applied as it is or there are some infrastructure
changes required?
[Oops, I thought I sent this days ago.]
Hi Yegor.
Yep, it was me. That change is unacceptable though, see:
http://www.spinics.net/lists/arm-kernel/msg168865.html
You were testing on linux-omap/master? If so, hmmm, I thought
that branch would work. For now, you can try adding 'nohlt'
to the cmdline but that's a bit of a sledgehammer...
Mark
--
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
Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji: 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. This is Apacer 2GB. In 3.3-rc7 I have no problems with it. Should I enable debugging in 3.3-rc7 and post the output? Best regards, Yegor -- 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
Am 20.07.2012 09:39, schrieb Yegor Yefremov:
Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji:
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.
This is Apacer 2GB. In 3.3-rc7 I have no problems with it. Should I enable
debugging in 3.3-rc7 and post the output?
I found the solution:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4fc88c..0ab26ab 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -359,7 +359,7 @@ static void omap3_pm_idle(void)
{
local_fiq_disable();
- if (omap_irq_pending())
+ if (omap_irq_pending() || !omap3_has_io_wakeup())
goto out;
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
I've seen this hack for some on the mailing list. I think Mark A. Greer
introduced it, but I don't remember for sure. Can this patch be applied as it
is or there are some infrastructure changes required?
Best regards,
Yegor
--
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
am3517: geting MMC working
What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. Best regards, Yegor -- 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 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. Regards Santosh [1] http://www.spinics.net/lists/linux-omap/msg73965.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: am3517: geting MMC working
Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. [1] http://www.spinics.net/lists/linux-omap/msg73703.html Yegor -- 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 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am3517: geting MMC working
Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 6, 294912 bytes) TCP: Hash tables configured (established
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
Re: am3517: geting MMC working
Am 19.07.2012 09:43, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol family 2 IP route cache
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 9:43 AM, S, Venkatraman svenk...@ti.com wrote: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource 32k_counter NET: Registered protocol
Re: am3517: geting MMC working
On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:43, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211: Calling CRDA to update world regulatory domain
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: am3517: geting MMC working
Am 19.07.2012 10:57, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:43, schrieb S, Venkatraman: On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov yegor_s...@visionsystems.de wrote: Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov yegor_s...@visionsystems.de wrote: What patches do I need to get MMC working with linux-omap master? omap_hsmmc omap_hsmmc.0: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 62 omap-dma-engine omap-dma-engine: allocating channel for 61 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk omap-dma-engine omap-dma-engine: allocating channel for 48 omap-dma-engine omap-dma-engine: allocating channel for 47 I searched for this issue and saw some patches for common clock framework that were scheduled for 3.6, but I'm not sure it's enough or weather they are already incorporated in linux-omap. I guess you need [1] to get around the issue. [1] http://www.spinics.net/lists/linux-omap/msg73965.html though I haven't applied this patch I have DMA activated (CONFIG_DMADEVICES and CONFIG_DMA_OMAP). Found in some other thread [1]. As far as I can tell, debounce clk is the problem. Sorry. I miss-read the message. The whole log for reference: Booting Linux on physical CPU 0 Linux version 3.5.0-rc6-12227-g60701f4-dirty () (gcc version 4.5.3 (Buildroot 2012.05-rc2-9-gfbd5a1d-dirty) ) #90 Thu Jul 19 09:23:31 CEST 2012 CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3517/AM3517 EVM Ignoring tag cmdline (using the default kernel command line) bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback AM3517 ES1.1 (l2cache sgx neon ) Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk=serial,ttyO2,115200 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 255MB = 255MB total Memory: 247380k/247380k available, 14764k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xd080 - 0xff00 ( 744 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc055e6a8 (5466 kB) .init : 0xc055f000 - 0xc0594874 ( 215 kB) .data : 0xc0596000 - 0xc05fccc0 ( 412 kB) .bss : 0xc05fcce4 - 0xc0b2a1e8 (5302 kB) NR_IRQS:474 IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP clockevent source: GPTIMER1 at 32768 Hz sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms OMAP clocksource: 32k_counter at 32768 Hz Console: colour dummy device 80x30 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS:8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 3695 kB per task-struct memory footprint: 1152 bytes Calibrating delay loop... 331.40 BogoMIPS (lpj=1296384) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0x80444ff0 - 0x80445048 devtmpfs: initialized dummy: NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 omap_mux_init: Add partition: #1: core, flags: 0 _omap_mux_get_by_name: Could not find signal uart4_rx.uart4_rx Reprogramming SDRC clock to 33200 Hz dpll3_m2_clk rate change failed: -22 hw-breakpoint: debug architecture 0x4 unsupported. OMAP DMA hardware revision 4.0 bio: create slab bio-0 at 0 omap-dma-engine omap-dma-engine: OMAP DMA engine driver SCSI subsystem initialized omap_i2c omap_i2c.1: bus 1 rev1.3.12 at 400 kHz omap_i2c omap_i2c.2: bus 2 rev1.3.12 at 400 kHz omap_i2c omap_i2c.3: bus 3 rev1.3.12 at 400 kHz Bluetooth: Core ver 2.16 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP socket layer initialized Bluetooth: SCO socket layer initialized cfg80211:
Re: am3517: geting MMC working
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? - 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
