public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* 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  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

* 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

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