* am3517: geting MMC working @ 2012-07-19 6:24 Yegor Yefremov 2012-07-19 6:34 ` Shilimkar, Santosh 0 siblings, 1 reply; 16+ messages in thread From: Yegor Yefremov @ 2012-07-19 6:24 UTC (permalink / raw) To: linux-omap@vger.kernel.org; +Cc: Mark A. Greer, Porter, Matt 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 6:24 am3517: geting MMC working Yegor Yefremov @ 2012-07-19 6:34 ` Shilimkar, Santosh 2012-07-19 6:55 ` Yegor Yefremov 0 siblings, 1 reply; 16+ messages in thread From: Shilimkar, Santosh @ 2012-07-19 6:34 UTC (permalink / raw) To: yegor_sub1; +Cc: linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov <yegor_sub1@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 6:34 ` Shilimkar, Santosh @ 2012-07-19 6:55 ` Yegor Yefremov 2012-07-19 7:07 ` Shilimkar, Santosh 0 siblings, 1 reply; 16+ messages in thread From: Yegor Yefremov @ 2012-07-19 6:55 UTC (permalink / raw) To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: > On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov > <yegor_sub1@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 6:55 ` Yegor Yefremov @ 2012-07-19 7:07 ` Shilimkar, Santosh 2012-07-19 7:28 ` Yegor Yefremov 0 siblings, 1 reply; 16+ messages in thread From: Shilimkar, Santosh @ 2012-07-19 7:07 UTC (permalink / raw) To: yegor_sub1; +Cc: linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov <yegor_sub1@visionsystems.de> wrote: > Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >> <yegor_sub1@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 7:07 ` Shilimkar, Santosh @ 2012-07-19 7:28 ` Yegor Yefremov 2012-07-19 7:43 ` S, Venkatraman 0 siblings, 1 reply; 16+ messages in thread From: Yegor Yefremov @ 2012-07-19 7:28 UTC (permalink / raw) To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: > On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov > <yegor_sub1@visionsystems.de> wrote: >> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >>> <yegor_sub1@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-00009-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 : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 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 0xfa200000 (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 332000000 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 8192 bind 8192) TCP: reno registered UDP hash table entries: 256 (order: 2, 20480 bytes) UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. NetWinder Floating Point Emulator V0.97 (double precision) VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) NFS: Registering the id_resolver key type Key type id_resolver registered jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. msgmni has been set to 483 io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 console [ttyO2] enabled, bootconsole disabled console [ttyO2] enabled, bootconsole disabled omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3 brd: module loaded loop: module loaded mtdoops: mtd device (mtddev=name/number) must be supplied OneNAND driver initializing davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 davinci_mdio davinci_mdio.0: detected phy mask fffffffd davinci_mdio.0: probed davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver unknown mousedev: PS/2 mouse device common for all mice i2c /dev entries driver omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec Bluetooth: HCI UART driver ver 2.2 Bluetooth: HCI H4 protocol initialized Bluetooth: HCI BCSP protocol initialized Bluetooth: HCILL protocol initialized 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 oprofile: hardware counters not available oprofile: using timer interrupt. TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 NET: Registered protocol family 15 lib80211: common routines for IEEE802.11 drivers Key type dns_resolver registered VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 voltdm_scale: No voltage scale API registered for vdd_mpu_iva voltdm_scale: No voltage scale API registered for vdd_core PM: no software I/O chain control; some wakeups may be lost ThumbEE CPU extension supported. clock: disabling unused clocks to save power davinci_emac davinci_emac.0: using random MAC addr: 9a:df:69:5d:52:ee Waiting for root device /dev/mmcblk0p2... mmc0: host does not support reading read-only switch. assuming write-enable. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 7:28 ` Yegor Yefremov @ 2012-07-19 7:43 ` S, Venkatraman 2012-07-19 8:15 ` Yegor Yefremov 2012-07-19 8:46 ` Javier Martinez Canillas 0 siblings, 2 replies; 16+ messages in thread From: S, Venkatraman @ 2012-07-19 7:43 UTC (permalink / raw) To: yegor_sub1 Cc: Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt, Balaji T Krishnamoorthy On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov <yegor_sub1@visionsystems.de> wrote: > Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: >> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov >> <yegor_sub1@visionsystems.de> wrote: >>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >>>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >>>> <yegor_sub1@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-00009-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 : 0xffff0000 - 0xffff1000 ( 4 kB) > fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) > vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) > lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) > pkmap : 0xbfe00000 - 0xc0000000 ( 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 0xfa200000 (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 332000000 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 8192 bind 8192) > TCP: reno registered > UDP hash table entries: 256 (order: 2, 20480 bytes) > UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) > NET: Registered protocol family 1 > RPC: Registered named UNIX socket transport module. > RPC: Registered udp transport module. > RPC: Registered tcp transport module. > RPC: Registered tcp NFSv4.1 backchannel transport module. > NetWinder Floating Point Emulator V0.97 (double precision) > VFS: Disk quotas dquot_6.5.2 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > NFS: Registering the id_resolver key type > Key type id_resolver registered > jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. > msgmni has been set to 483 > io scheduler noop registered > io scheduler deadline registered > io scheduler cfq registered (default) > Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 > omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 > omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 > console [ttyO2] enabled, bootconsole disabled > console [ttyO2] enabled, bootconsole disabled > omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3 > brd: module loaded > loop: module loaded > mtdoops: mtd device (mtddev=name/number) must be supplied > OneNAND driver initializing > davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 > davinci_mdio davinci_mdio.0: detected phy mask fffffffd > davinci_mdio.0: probed > davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver unknown > mousedev: PS/2 mouse device common for all mice > i2c /dev entries driver > omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec > Bluetooth: HCI UART driver ver 2.2 > Bluetooth: HCI H4 protocol initialized > Bluetooth: HCI BCSP protocol initialized > Bluetooth: HCILL protocol initialized > 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 > oprofile: hardware counters not available > oprofile: using timer interrupt. > TCP: cubic registered > Initializing XFRM netlink socket > NET: Registered protocol family 17 > NET: Registered protocol family 15 > lib80211: common routines for IEEE802.11 drivers > Key type dns_resolver registered > VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 > voltdm_scale: No voltage scale API registered for vdd_mpu_iva > voltdm_scale: No voltage scale API registered for vdd_core > PM: no software I/O chain control; some wakeups may be lost > ThumbEE CPU extension supported. > clock: disabling unused clocks to save power > davinci_emac davinci_emac.0: using random MAC addr: 9a:df:69:5d:52:ee > Waiting for root device /dev/mmcblk0p2... > mmc0: host does not support reading read-only switch. assuming write-enable. > -- Debouce clocks failures are non fatal, and are present in OMAP2xxx only. (I don't know about AM35xx, but most likely its not present). The last 2 lines shows that mmc0 is enumerated, but the boot partition is not. If possible, can you please provide logs with MMC_DEBUG enabled at compile time and a verbose loglevel (loglevel=8) ? Thanks, Venkat. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 7:43 ` S, Venkatraman @ 2012-07-19 8:15 ` Yegor Yefremov 2012-07-19 8:57 ` S, Venkatraman 2012-07-19 8:46 ` Javier Martinez Canillas 1 sibling, 1 reply; 16+ messages in thread From: Yegor Yefremov @ 2012-07-19 8:15 UTC (permalink / raw) To: S, Venkatraman Cc: Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt, Balaji T Krishnamoorthy Am 19.07.2012 09:43, schrieb S, Venkatraman: > On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov > <yegor_sub1@visionsystems.de> wrote: >> Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: >>> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov >>> <yegor_sub1@visionsystems.de> wrote: >>>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >>>>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >>>>> <yegor_sub1@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-00009-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 : 0xffff0000 - 0xffff1000 ( 4 kB) >> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) >> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) >> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) >> pkmap : 0xbfe00000 - 0xc0000000 ( 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 0xfa200000 (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 332000000 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 8192 bind 8192) >> TCP: reno registered >> UDP hash table entries: 256 (order: 2, 20480 bytes) >> UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) >> NET: Registered protocol family 1 >> RPC: Registered named UNIX socket transport module. >> RPC: Registered udp transport module. >> RPC: Registered tcp transport module. >> RPC: Registered tcp NFSv4.1 backchannel transport module. >> NetWinder Floating Point Emulator V0.97 (double precision) >> VFS: Disk quotas dquot_6.5.2 >> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) >> NFS: Registering the id_resolver key type >> Key type id_resolver registered >> jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. >> msgmni has been set to 483 >> io scheduler noop registered >> io scheduler deadline registered >> io scheduler cfq registered (default) >> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled >> omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >> omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >> omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 >> console [ttyO2] enabled, bootconsole disabled >> console [ttyO2] enabled, bootconsole disabled >> omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3 >> brd: module loaded >> loop: module loaded >> mtdoops: mtd device (mtddev=name/number) must be supplied >> OneNAND driver initializing >> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 >> davinci_mdio davinci_mdio.0: detected phy mask fffffffd >> davinci_mdio.0: probed >> davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver unknown >> mousedev: PS/2 mouse device common for all mice >> i2c /dev entries driver >> omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec >> Bluetooth: HCI UART driver ver 2.2 >> Bluetooth: HCI H4 protocol initialized >> Bluetooth: HCI BCSP protocol initialized >> Bluetooth: HCILL protocol initialized >> 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 >> oprofile: hardware counters not available >> oprofile: using timer interrupt. >> TCP: cubic registered >> Initializing XFRM netlink socket >> NET: Registered protocol family 17 >> NET: Registered protocol family 15 >> lib80211: common routines for IEEE802.11 drivers >> Key type dns_resolver registered >> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 >> voltdm_scale: No voltage scale API registered for vdd_mpu_iva >> voltdm_scale: No voltage scale API registered for vdd_core >> PM: no software I/O chain control; some wakeups may be lost >> ThumbEE CPU extension supported. >> clock: disabling unused clocks to save power >> davinci_emac davinci_emac.0: using random MAC addr: 9a:df:69:5d:52:ee >> Waiting for root device /dev/mmcblk0p2... >> mmc0: host does not support reading read-only switch. assuming write-enable. >> -- > Debouce clocks failures are non fatal, and are present in OMAP2xxx only. > (I don't know about AM35xx, but most likely its not present). You're right: http://old.nabble.com/-PATCH-V2--omap_hsmmc:-Fix-for-the-db-clock-failure-message-td25047778.html > The last 2 lines shows that mmc0 is enumerated, but the boot partition is not. > If possible, can you please provide logs with MMC_DEBUG enabled at compile time > and a verbose loglevel (loglevel=8) ? Bluetooth: HCI UART driver ver 2.2 Bluetooth: HCI H4 protocol initialized Bluetooth: HCI BCSP protocol initialized Bluetooth: HCILL protocol initialized omap_hsmmc omap_hsmmc.0: context was not lost omap_hsmmc omap_hsmmc.0: enabled 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 mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 19 width 0 timing 0 omap_hsmmc omap_hsmmc.0: Set clock to 0Hz mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz omap_hsmmc omap_hsmmc.0: disabled omap_hsmmc omap_hsmmc.1: context was not lost omap_hsmmc omap_hsmmc.1: enabled 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 omap_hsmmc omap_hsmmc.0: context was not lost omap_hsmmc omap_hsmmc.0: enabled mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz mmc0: starting CMD52 arg 00000c00 flags 00000195 omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x00000c00 omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000 mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 19 width 0 timing 0 omap_hsmmc omap_hsmmc.1: Set clock to 0Hz mmc0: starting CMD52 arg 80000c08 flags 00000195 omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x80000c08 omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000 mmc1: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 omap_hsmmc omap_hsmmc.1: Set clock to 400000Hz mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 19 width 0 timing 0 omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz mmc0: starting CMD0 arg 00000000 flags 000000c0 omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 1 mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000 omap_hsmmc omap_hsmmc.1: disabled mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz oprofile: hardware counters not available oprofile: using timer interrupt. TCP: cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 NET: Registered protocol family 15 lib80211: common routines for IEEE802.11 drivers lib80211_crypt: registered algorithm 'NULL' Key type dns_resolver registered VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 voltdm_scale: No voltage scale API registered for vdd_mpu_iva voltdm_scale: No voltage scale API registered for vdd_core PM: no software I/O chain control; some wakeups may be lost ThumbEE CPU extension supported. clock: disabling unused clocks to save power mmc0: starting CMD8 arg 000001aa flags 000002f5 omap_hsmmc omap_hsmmc.0: mmc0: CMD8, argument 0x000001aa omap_hsmmc omap_hsmmc.0: IRQ Status is 1 mmc0: req done (CMD8): 0: 000001aa 00000000 00000000 00000000 mmc0: starting CMD5 arg 00000000 flags 000002e1 omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req failed (CMD5): -110, retrying... omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req failed (CMD5): -110, retrying... omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO davinci_emac davinci_emac.0: using random MAC addr: 0a:e0:2b:8a:d1:27 mmc0: req failed (CMD5): -110, retrying... omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000 mmc0: starting CMD55 arg 00000000 flags 000000f5 omap_hsmmc omap_hsmmc.0: mmc0: CMD55, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 1 mmc0: req done (CMD55): 0: 00400120 00000000 00000000 00000000 mmc0: starting CMD41 arg 00000000 flags 000000e1 omap_hsmmc omap_hsmmc.0: mmc0: CMD41, argument 0x00000000 omap_hsmmc omap_hsmmc.0: IRQ Status is 1 mmc0: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000 mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 15 width 0 timing 0 omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 15 width 0 timing 0 omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz Waiting for root device /dev/mmcblk0p2... mmc0: starting CMD0 arg 00000000 flags 000000c0 omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 8:15 ` Yegor Yefremov @ 2012-07-19 8:57 ` S, Venkatraman 2012-07-19 10:08 ` T Krishnamoorthy, Balaji ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: S, Venkatraman @ 2012-07-19 8:57 UTC (permalink / raw) To: yegor_sub1 Cc: Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt, Balaji T Krishnamoorthy On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov <yegor_sub1@visionsystems.de> wrote: > Am 19.07.2012 09:43, schrieb S, Venkatraman: >> On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov >> <yegor_sub1@visionsystems.de> wrote: >>> Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: >>>> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov >>>> <yegor_sub1@visionsystems.de> wrote: >>>>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >>>>>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >>>>>> <yegor_sub1@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-00009-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 : 0xffff0000 - 0xffff1000 ( 4 kB) >>> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) >>> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) >>> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) >>> pkmap : 0xbfe00000 - 0xc0000000 ( 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 0xfa200000 (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 332000000 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 8192 bind 8192) >>> TCP: reno registered >>> UDP hash table entries: 256 (order: 2, 20480 bytes) >>> UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) >>> NET: Registered protocol family 1 >>> RPC: Registered named UNIX socket transport module. >>> RPC: Registered udp transport module. >>> RPC: Registered tcp transport module. >>> RPC: Registered tcp NFSv4.1 backchannel transport module. >>> NetWinder Floating Point Emulator V0.97 (double precision) >>> VFS: Disk quotas dquot_6.5.2 >>> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) >>> NFS: Registering the id_resolver key type >>> Key type id_resolver registered >>> jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. >>> msgmni has been set to 483 >>> io scheduler noop registered >>> io scheduler deadline registered >>> io scheduler cfq registered (default) >>> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled >>> omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >>> omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >>> omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 >>> console [ttyO2] enabled, bootconsole disabled >>> console [ttyO2] enabled, bootconsole disabled >>> omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3 >>> brd: module loaded >>> loop: module loaded >>> mtdoops: mtd device (mtddev=name/number) must be supplied >>> OneNAND driver initializing >>> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 >>> davinci_mdio davinci_mdio.0: detected phy mask fffffffd >>> davinci_mdio.0: probed >>> davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver unknown >>> mousedev: PS/2 mouse device common for all mice >>> i2c /dev entries driver >>> omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec >>> Bluetooth: HCI UART driver ver 2.2 >>> Bluetooth: HCI H4 protocol initialized >>> Bluetooth: HCI BCSP protocol initialized >>> Bluetooth: HCILL protocol initialized >>> 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 >>> oprofile: hardware counters not available >>> oprofile: using timer interrupt. >>> TCP: cubic registered >>> Initializing XFRM netlink socket >>> NET: Registered protocol family 17 >>> NET: Registered protocol family 15 >>> lib80211: common routines for IEEE802.11 drivers >>> Key type dns_resolver registered >>> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 >>> voltdm_scale: No voltage scale API registered for vdd_mpu_iva >>> voltdm_scale: No voltage scale API registered for vdd_core >>> PM: no software I/O chain control; some wakeups may be lost >>> ThumbEE CPU extension supported. >>> clock: disabling unused clocks to save power >>> davinci_emac davinci_emac.0: using random MAC addr: 9a:df:69:5d:52:ee >>> Waiting for root device /dev/mmcblk0p2... >>> mmc0: host does not support reading read-only switch. assuming write-enable. >>> -- >> Debouce clocks failures are non fatal, and are present in OMAP2xxx only. >> (I don't know about AM35xx, but most likely its not present). > > You're right: > http://old.nabble.com/-PATCH-V2--omap_hsmmc:-Fix-for-the-db-clock-failure-message-td25047778.html > >> The last 2 lines shows that mmc0 is enumerated, but the boot partition is not. >> If possible, can you please provide logs with MMC_DEBUG enabled at compile time >> and a verbose loglevel (loglevel=8) ? > > Bluetooth: HCI UART driver ver 2.2 > Bluetooth: HCI H4 protocol initialized > Bluetooth: HCI BCSP protocol initialized > Bluetooth: HCILL protocol initialized > omap_hsmmc omap_hsmmc.0: context was not lost > omap_hsmmc omap_hsmmc.0: enabled > 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 > mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 19 width 0 timing 0 > omap_hsmmc omap_hsmmc.0: Set clock to 0Hz > mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 > omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz > omap_hsmmc omap_hsmmc.0: disabled > omap_hsmmc omap_hsmmc.1: context was not lost > omap_hsmmc omap_hsmmc.1: enabled > 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 > omap_hsmmc omap_hsmmc.0: context was not lost > omap_hsmmc omap_hsmmc.0: enabled > mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz > mmc0: starting CMD52 arg 00000c00 flags 00000195 > omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x00000c00 > omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 > omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO > mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000 > mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 19 width 0 timing 0 > omap_hsmmc omap_hsmmc.1: Set clock to 0Hz > mmc0: starting CMD52 arg 80000c08 flags 00000195 > omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x80000c08 > omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 > omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO > mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000 > mmc1: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 > omap_hsmmc omap_hsmmc.1: Set clock to 400000Hz > mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 19 width 0 timing 0 > omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz > mmc0: starting CMD0 arg 00000000 flags 000000c0 > omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 1 > mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000 > omap_hsmmc omap_hsmmc.1: disabled > mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 > omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz > oprofile: hardware counters not available > oprofile: using timer interrupt. > TCP: cubic registered > Initializing XFRM netlink socket > NET: Registered protocol family 17 > NET: Registered protocol family 15 > lib80211: common routines for IEEE802.11 drivers > lib80211_crypt: registered algorithm 'NULL' > Key type dns_resolver registered > VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 > voltdm_scale: No voltage scale API registered for vdd_mpu_iva > voltdm_scale: No voltage scale API registered for vdd_core > PM: no software I/O chain control; some wakeups may be lost > ThumbEE CPU extension supported. > clock: disabling unused clocks to save power > mmc0: starting CMD8 arg 000001aa flags 000002f5 > omap_hsmmc omap_hsmmc.0: mmc0: CMD8, argument 0x000001aa > omap_hsmmc omap_hsmmc.0: IRQ Status is 1 > mmc0: req done (CMD8): 0: 000001aa 00000000 00000000 00000000 > mmc0: starting CMD5 arg 00000000 flags 000002e1 > omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 > omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO > mmc0: req failed (CMD5): -110, retrying... > omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 > omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO > mmc0: req failed (CMD5): -110, retrying... > omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 > omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO > davinci_emac davinci_emac.0: using random MAC addr: 0a:e0:2b:8a:d1:27 > mmc0: req failed (CMD5): -110, retrying... > omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 > omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO > mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000 > mmc0: starting CMD55 arg 00000000 flags 000000f5 > omap_hsmmc omap_hsmmc.0: mmc0: CMD55, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 1 > mmc0: req done (CMD55): 0: 00400120 00000000 00000000 00000000 > mmc0: starting CMD41 arg 00000000 flags 000000e1 > omap_hsmmc omap_hsmmc.0: mmc0: CMD41, argument 0x00000000 > omap_hsmmc omap_hsmmc.0: IRQ Status is 1 > mmc0: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000 > mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 15 width 0 timing 0 > omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz > mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 15 width 0 timing 0 > omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz > Waiting for root device /dev/mmcblk0p2... > mmc0: starting CMD0 arg 00000000 flags 000000c0 > omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 8:57 ` S, Venkatraman @ 2012-07-19 10:08 ` T Krishnamoorthy, Balaji 2012-07-19 13:45 ` Yegor Yefremov 2012-07-19 21:38 ` Paul Walmsley 2 siblings, 0 replies; 16+ messages in thread From: T Krishnamoorthy, Balaji @ 2012-07-19 10:08 UTC (permalink / raw) To: S, Venkatraman, yegor_sub1 Cc: Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt On Thu, Jul 19, 2012 at 2:27 PM, S, Venkatraman <svenkatr@ti.com> wrote: > On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov > <yegor_sub1@visionsystems.de> wrote: >> Waiting for root device /dev/mmcblk0p2... >> mmc0: starting CMD0 arg 00000000 flags 000000c0 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 >> > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 8:57 ` S, Venkatraman 2012-07-19 10:08 ` T Krishnamoorthy, Balaji @ 2012-07-19 13:45 ` Yegor Yefremov 2012-07-19 21:38 ` Paul Walmsley 2 siblings, 0 replies; 16+ messages in thread From: Yegor Yefremov @ 2012-07-19 13:45 UTC (permalink / raw) To: S, Venkatraman Cc: Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt, Balaji T Krishnamoorthy Am 19.07.2012 10:57, schrieb S, Venkatraman: > On Thu, Jul 19, 2012 at 1:45 PM, Yegor Yefremov > <yegor_sub1@visionsystems.de> wrote: >> Am 19.07.2012 09:43, schrieb S, Venkatraman: >>> On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov >>> <yegor_sub1@visionsystems.de> wrote: >>>> Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: >>>>> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov >>>>> <yegor_sub1@visionsystems.de> wrote: >>>>>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >>>>>>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >>>>>>> <yegor_sub1@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-00009-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 : 0xffff0000 - 0xffff1000 ( 4 kB) >>>> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) >>>> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) >>>> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) >>>> pkmap : 0xbfe00000 - 0xc0000000 ( 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 0xfa200000 (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 332000000 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 8192 bind 8192) >>>> TCP: reno registered >>>> UDP hash table entries: 256 (order: 2, 20480 bytes) >>>> UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) >>>> NET: Registered protocol family 1 >>>> RPC: Registered named UNIX socket transport module. >>>> RPC: Registered udp transport module. >>>> RPC: Registered tcp transport module. >>>> RPC: Registered tcp NFSv4.1 backchannel transport module. >>>> NetWinder Floating Point Emulator V0.97 (double precision) >>>> VFS: Disk quotas dquot_6.5.2 >>>> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) >>>> NFS: Registering the id_resolver key type >>>> Key type id_resolver registered >>>> jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. >>>> msgmni has been set to 483 >>>> io scheduler noop registered >>>> io scheduler deadline registered >>>> io scheduler cfq registered (default) >>>> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled >>>> omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >>>> omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >>>> omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 >>>> console [ttyO2] enabled, bootconsole disabled >>>> console [ttyO2] enabled, bootconsole disabled >>>> omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3 >>>> brd: module loaded >>>> loop: module loaded >>>> mtdoops: mtd device (mtddev=name/number) must be supplied >>>> OneNAND driver initializing >>>> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 >>>> davinci_mdio davinci_mdio.0: detected phy mask fffffffd >>>> davinci_mdio.0: probed >>>> davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver unknown >>>> mousedev: PS/2 mouse device common for all mice >>>> i2c /dev entries driver >>>> omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec >>>> Bluetooth: HCI UART driver ver 2.2 >>>> Bluetooth: HCI H4 protocol initialized >>>> Bluetooth: HCI BCSP protocol initialized >>>> Bluetooth: HCILL protocol initialized >>>> 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 >>>> oprofile: hardware counters not available >>>> oprofile: using timer interrupt. >>>> TCP: cubic registered >>>> Initializing XFRM netlink socket >>>> NET: Registered protocol family 17 >>>> NET: Registered protocol family 15 >>>> lib80211: common routines for IEEE802.11 drivers >>>> Key type dns_resolver registered >>>> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 >>>> voltdm_scale: No voltage scale API registered for vdd_mpu_iva >>>> voltdm_scale: No voltage scale API registered for vdd_core >>>> PM: no software I/O chain control; some wakeups may be lost >>>> ThumbEE CPU extension supported. >>>> clock: disabling unused clocks to save power >>>> davinci_emac davinci_emac.0: using random MAC addr: 9a:df:69:5d:52:ee >>>> Waiting for root device /dev/mmcblk0p2... >>>> mmc0: host does not support reading read-only switch. assuming write-enable. >>>> -- >>> Debouce clocks failures are non fatal, and are present in OMAP2xxx only. >>> (I don't know about AM35xx, but most likely its not present). >> You're right: >> http://old.nabble.com/-PATCH-V2--omap_hsmmc:-Fix-for-the-db-clock-failure-message-td25047778.html >> >>> The last 2 lines shows that mmc0 is enumerated, but the boot partition is not. >>> If possible, can you please provide logs with MMC_DEBUG enabled at compile time >>> and a verbose loglevel (loglevel=8) ? >> Bluetooth: HCI UART driver ver 2.2 >> Bluetooth: HCI H4 protocol initialized >> Bluetooth: HCI BCSP protocol initialized >> Bluetooth: HCILL protocol initialized >> omap_hsmmc omap_hsmmc.0: context was not lost >> omap_hsmmc omap_hsmmc.0: enabled >> 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 >> mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 19 width 0 timing 0 >> omap_hsmmc omap_hsmmc.0: Set clock to 0Hz >> mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 >> omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz >> omap_hsmmc omap_hsmmc.0: disabled >> omap_hsmmc omap_hsmmc.1: context was not lost >> omap_hsmmc omap_hsmmc.1: enabled >> 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 >> omap_hsmmc omap_hsmmc.0: context was not lost >> omap_hsmmc omap_hsmmc.0: enabled >> mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz >> mmc0: starting CMD52 arg 00000c00 flags 00000195 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x00000c00 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 >> omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO >> mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000 >> mmc1: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 19 width 0 timing 0 >> omap_hsmmc omap_hsmmc.1: Set clock to 0Hz >> mmc0: starting CMD52 arg 80000c08 flags 00000195 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x80000c08 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 >> omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO >> mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000 >> mmc1: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 >> omap_hsmmc omap_hsmmc.1: Set clock to 400000Hz >> mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 19 width 0 timing 0 >> omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz >> mmc0: starting CMD0 arg 00000000 flags 000000c0 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 1 >> mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000 >> omap_hsmmc omap_hsmmc.1: disabled >> mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 19 width 0 timing 0 >> omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz >> oprofile: hardware counters not available >> oprofile: using timer interrupt. >> TCP: cubic registered >> Initializing XFRM netlink socket >> NET: Registered protocol family 17 >> NET: Registered protocol family 15 >> lib80211: common routines for IEEE802.11 drivers >> lib80211_crypt: registered algorithm 'NULL' >> Key type dns_resolver registered >> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 >> voltdm_scale: No voltage scale API registered for vdd_mpu_iva >> voltdm_scale: No voltage scale API registered for vdd_core >> PM: no software I/O chain control; some wakeups may be lost >> ThumbEE CPU extension supported. >> clock: disabling unused clocks to save power >> mmc0: starting CMD8 arg 000001aa flags 000002f5 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD8, argument 0x000001aa >> omap_hsmmc omap_hsmmc.0: IRQ Status is 1 >> mmc0: req done (CMD8): 0: 000001aa 00000000 00000000 00000000 >> mmc0: starting CMD5 arg 00000000 flags 000002e1 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 >> omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO >> mmc0: req failed (CMD5): -110, retrying... >> omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 >> omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO >> mmc0: req failed (CMD5): -110, retrying... >> omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 >> omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO >> davinci_emac davinci_emac.0: using random MAC addr: 0a:e0:2b:8a:d1:27 >> mmc0: req failed (CMD5): -110, retrying... >> omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 >> omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO >> mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000 >> mmc0: starting CMD55 arg 00000000 flags 000000f5 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD55, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 1 >> mmc0: req done (CMD55): 0: 00400120 00000000 00000000 00000000 >> mmc0: starting CMD41 arg 00000000 flags 000000e1 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD41, argument 0x00000000 >> omap_hsmmc omap_hsmmc.0: IRQ Status is 1 >> mmc0: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000 >> mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 15 width 0 timing 0 >> omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz >> mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 15 width 0 timing 0 >> omap_hsmmc omap_hsmmc.0: Set clock to 400000Hz >> Waiting for root device /dev/mmcblk0p2... >> mmc0: starting CMD0 arg 00000000 flags 000000c0 >> omap_hsmmc omap_hsmmc.0: mmc0: CMD0, argument 0x00000000 >> > >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. WIll bissect. Thanks for help. Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 8:57 ` S, Venkatraman 2012-07-19 10:08 ` T Krishnamoorthy, Balaji 2012-07-19 13:45 ` Yegor Yefremov @ 2012-07-19 21:38 ` Paul Walmsley 2012-07-20 7:28 ` T Krishnamoorthy, Balaji 2 siblings, 1 reply; 16+ messages in thread From: Paul Walmsley @ 2012-07-19 21:38 UTC (permalink / raw) To: S, Venkatraman Cc: yegor_sub1, Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt, Balaji T Krishnamoorthy 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 21:38 ` Paul Walmsley @ 2012-07-20 7:28 ` T Krishnamoorthy, Balaji 2012-07-20 7:39 ` Yegor Yefremov 0 siblings, 1 reply; 16+ messages in thread From: T Krishnamoorthy, Balaji @ 2012-07-20 7:28 UTC (permalink / raw) To: Paul Walmsley Cc: S, Venkatraman, yegor_sub1, Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley <paul@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-20 7:28 ` T Krishnamoorthy, Balaji @ 2012-07-20 7:39 ` Yegor Yefremov 2012-07-20 8:01 ` Yegor Yefremov 0 siblings, 1 reply; 16+ messages in thread From: Yegor Yefremov @ 2012-07-20 7:39 UTC (permalink / raw) To: T Krishnamoorthy, Balaji Cc: Paul Walmsley, S, Venkatraman, Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt Am 20.07.2012 09:28, schrieb T Krishnamoorthy, Balaji: > On Fri, Jul 20, 2012 at 3:08 AM, Paul Walmsley <paul@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-20 7:39 ` Yegor Yefremov @ 2012-07-20 8:01 ` Yegor Yefremov 2012-07-26 23:31 ` Mark A. Greer 0 siblings, 1 reply; 16+ messages in thread From: Yegor Yefremov @ 2012-07-20 8:01 UTC (permalink / raw) To: T Krishnamoorthy, Balaji Cc: Paul Walmsley, S, Venkatraman, Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt 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 <paul@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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-20 8:01 ` Yegor Yefremov @ 2012-07-26 23:31 ` Mark A. Greer 0 siblings, 0 replies; 16+ messages in thread From: Mark A. Greer @ 2012-07-26 23:31 UTC (permalink / raw) To: Yegor Yefremov Cc: T Krishnamoorthy, Balaji, Paul Walmsley, S, Venkatraman, Shilimkar, Santosh, linux-omap@vger.kernel.org, Porter, Matt 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 <paul@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: am3517: geting MMC working 2012-07-19 7:43 ` S, Venkatraman 2012-07-19 8:15 ` Yegor Yefremov @ 2012-07-19 8:46 ` Javier Martinez Canillas 1 sibling, 0 replies; 16+ messages in thread From: Javier Martinez Canillas @ 2012-07-19 8:46 UTC (permalink / raw) To: S, Venkatraman Cc: yegor_sub1, Shilimkar, Santosh, linux-omap@vger.kernel.org, Mark A. Greer, Porter, Matt, Balaji T Krishnamoorthy On Thu, Jul 19, 2012 at 9:43 AM, S, Venkatraman <svenkatr@ti.com> wrote: > On Thu, Jul 19, 2012 at 12:58 PM, Yegor Yefremov > <yegor_sub1@visionsystems.de> wrote: >> Am 19.07.2012 09:07, schrieb Shilimkar, Santosh: >>> On Thu, Jul 19, 2012 at 12:25 PM, Yegor Yefremov >>> <yegor_sub1@visionsystems.de> wrote: >>>> Am 19.07.2012 08:34, schrieb Shilimkar, Santosh: >>>>> On Thu, Jul 19, 2012 at 11:54 AM, Yegor Yefremov >>>>> <yegor_sub1@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-00009-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 : 0xffff0000 - 0xffff1000 ( 4 kB) >> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) >> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) >> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) >> pkmap : 0xbfe00000 - 0xc0000000 ( 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 0xfa200000 (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 332000000 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 8192 bind 8192) >> TCP: reno registered >> UDP hash table entries: 256 (order: 2, 20480 bytes) >> UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) >> NET: Registered protocol family 1 >> RPC: Registered named UNIX socket transport module. >> RPC: Registered udp transport module. >> RPC: Registered tcp transport module. >> RPC: Registered tcp NFSv4.1 backchannel transport module. >> NetWinder Floating Point Emulator V0.97 (double precision) >> VFS: Disk quotas dquot_6.5.2 >> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) >> NFS: Registering the id_resolver key type >> Key type id_resolver registered >> jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. >> msgmni has been set to 483 >> io scheduler noop registered >> io scheduler deadline registered >> io scheduler cfq registered (default) >> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled >> omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0 >> omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1 >> omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2 >> console [ttyO2] enabled, bootconsole disabled >> console [ttyO2] enabled, bootconsole disabled >> omap_uart.3: ttyO3 at MMIO 0x4809e000 (irq = 84) is a OMAP UART3 >> brd: module loaded >> loop: module loaded >> mtdoops: mtd device (mtddev=name/number) must be supplied >> OneNAND driver initializing >> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 >> davinci_mdio davinci_mdio.0: detected phy mask fffffffd >> davinci_mdio.0: probed >> davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio-0:01, driver unknown >> mousedev: PS/2 mouse device common for all mice >> i2c /dev entries driver >> omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec >> Bluetooth: HCI UART driver ver 2.2 >> Bluetooth: HCI H4 protocol initialized >> Bluetooth: HCI BCSP protocol initialized >> Bluetooth: HCILL protocol initialized >> 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 >> oprofile: hardware counters not available >> oprofile: using timer interrupt. >> TCP: cubic registered >> Initializing XFRM netlink socket >> NET: Registered protocol family 17 >> NET: Registered protocol family 15 >> lib80211: common routines for IEEE802.11 drivers >> Key type dns_resolver registered >> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 >> voltdm_scale: No voltage scale API registered for vdd_mpu_iva >> voltdm_scale: No voltage scale API registered for vdd_core >> PM: no software I/O chain control; some wakeups may be lost >> ThumbEE CPU extension supported. >> clock: disabling unused clocks to save power >> davinci_emac davinci_emac.0: using random MAC addr: 9a:df:69:5d:52:ee >> Waiting for root device /dev/mmcblk0p2... >> mmc0: host does not support reading read-only switch. assuming write-enable. >> -- > > Debouce clocks failures are non fatal, and are present in OMAP2xxx only. > (I don't know about AM35xx, but most likely its not present). > The last 2 lines shows that mmc0 is enumerated, but the boot partition is not. > If possible, can you please provide logs with MMC_DEBUG enabled at compile time > and a verbose loglevel (loglevel=8) ? > Hi Yegor, In case is of some help to you I had the exact problem than you on an IGEPv2 board (TI DM3730 OMAP3 board) But enabling CONFIG_DMA_OMAP and CONFIG_DMADEVICES solve it. Now on booting I have this log: [ 2.312866] omap_hsmmc omap_hsmmc.1: Failed to get debounce clk [ 2.319335] omap-dma-engine omap-dma-engine: allocating channel for 48 [ 2.326324] omap-dma-engine omap-dma-engine: allocating channel for 47 [ 2.377716] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk [ 2.384124] omap-dma-engine omap-dma-engine: allocating channel for 62 [ 2.390991] omap-dma-engine omap-dma-engine: allocating channel for 61 and the MMC is working well. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-07-26 23:31 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-07-19 6:24 am3517: geting MMC working Yegor Yefremov 2012-07-19 6:34 ` Shilimkar, Santosh 2012-07-19 6:55 ` Yegor Yefremov 2012-07-19 7:07 ` Shilimkar, Santosh 2012-07-19 7:28 ` Yegor Yefremov 2012-07-19 7:43 ` S, Venkatraman 2012-07-19 8:15 ` Yegor Yefremov 2012-07-19 8:57 ` S, Venkatraman 2012-07-19 10:08 ` T Krishnamoorthy, Balaji 2012-07-19 13:45 ` Yegor Yefremov 2012-07-19 21:38 ` Paul Walmsley 2012-07-20 7:28 ` T Krishnamoorthy, Balaji 2012-07-20 7:39 ` Yegor Yefremov 2012-07-20 8:01 ` Yegor Yefremov 2012-07-26 23:31 ` Mark A. Greer 2012-07-19 8:46 ` Javier Martinez Canillas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox