All of lore.kernel.org
 help / color / mirror / Atom feed
* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-04 13:25 ` Mark Jackson
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Jackson @ 2013-07-04 13:25 UTC (permalink / raw)
  To: linux-omap; +Cc: linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 15078 bytes --]

Our custom AM335x board has been booting just fine under 3.10.0-rc4.

I've just done a git pull to update to 3.10 (now that it's released)
and the board now hangs.

Before I start trying to bisect the issue, does anyone have an clues ?

I've attached my dotconfig.

Cheers
Mark J.

<<<< BAD BOOT >>>>

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-05288-g526a1a9-dirty (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #260 Thu Jul 4 13:43:19 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c05d2c84, node_mem_map c0b06000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: earlyprintk debug console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 rootfstype=jffs2 root=/dev/mtdblock4 ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 247508K/261120K available (4372K kernel code, 334K rwdata, 1016K rodata, 202K init, 5305K bss, 13612K reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc054b4e4   (5390 kB)
[    0.000000]       .init : 0xc054c000 - 0xc057eb74   ( 203 kB)
[    0.000000]       .data : 0xc0580000 - 0xc05d38a0   ( 335 kB)
[    0.000000]        .bss : 0xc05d38a0 - 0xc0b01f08   (5306 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: timer1 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062349] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)
[    0.119097] pid_max: default: 32768 minimum: 301
[    0.124246] Security Framework initialized
[    0.128690] Mount-cache hash table entries: 512
[    0.146814] CPU: Testing write buffer coherency: ok
[    0.153481] Setting up static identity map for 0xc0426b20 - 0xc0426b78
[    0.164988] devtmpfs: initialized

<<<< GOOD BOOT >>>>

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-rc4-00172-gf31c62e-dirty (mpfj@mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #259 Thu Jul 4 11:05:23 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c05c8a3c, node_mem_map c0afc000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: earlyprintk debug console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 rootfstype=jffs2 root=/dev/mtdblock4 ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 247552k/247552k available, 14592k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc054210c   (5353 kB)
[    0.000000]       .init : 0xc0543000 - 0xc05757ac   ( 202 kB)
[    0.000000]       .data : 0xc0576000 - 0xc05c9620   ( 334 kB)
[    0.000000]        .bss : 0xc05c9620 - 0xc0af7a88   (5306 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: timer1 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062209] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)
[    0.119227] pid_max: default: 32768 minimum: 301
[    0.124383] Security Framework initialized
[    0.128826] Mount-cache hash table entries: 512
[    0.145982] CPU: Testing write buffer coherency: ok
[    0.152707] Setting up static identity map for 0xc041ed88 - 0xc041ede0
[    0.164118] devtmpfs: initialized
[    0.173232] ttyO0 used as console in debug mode: uart0 clocks will not be gated
[    0.242012] pinctrl core: initialized pinctrl subsystem
[    0.252653] regulator-dummy: no parameters
[    0.260174] NET: Registered protocol family 16
[    0.265723] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.295484] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.303439] OMAP GPIO hardware version 0.1
[    0.310567] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.320495] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.330479] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.356857] omap-gpmc 50000000.gpmc: could not find pctldev for node /pinmux@44e10800/gpmc_pins, deferring probe
[    0.367516] platform 50000000.gpmc: Driver omap-gpmc requests probe deferral
[    0.375643] No ATAGs?
[    0.377853] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.385002] cpsw.0: No hwaddr in dt. Using c8:a0:30:83:91:be from efuse
[    0.391981] cpsw.1: No hwaddr in dt. Using c8:a0:30:83:91:bf from efuse
[    0.449213] bio: create slab <bio-0> at 0
[    0.463822] usbcore: registered new interface driver usbfs
[    0.470140] usbcore: registered new interface driver hub
[    0.476512] usbcore: registered new device driver usb
[    0.482966] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/i2c0_pins, deferring probe
[    0.493433] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    0.510569] cfg80211: Calling CRDA to update world regulatory domain
[    0.519405] Switching to clocksource timer1
[    0.585009] NET: Registered protocol family 2
[    0.591523] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.599211] TCP bind hash table entries: 2048 (order: 4, 73728 bytes)
[    0.607185] TCP: Hash tables configured (established 2048 bind 2048)
[    0.614144] TCP: reno registered
[    0.617577] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.624133] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.632359] NET: Registered protocol family 1
[    0.638659] RPC: Registered named UNIX socket transport module.
[    0.644927] RPC: Registered udp transport module.
[    0.649858] RPC: Registered tcp transport module.
[    0.654821] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.662640] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.683580] jffs2: version 2.2. © 2001-2006 Red Hat, Inc.
[    0.689959] msgmni has been set to 483
[    0.699227] io scheduler noop registered
[    0.703370] io scheduler deadline registered
[    0.707997] io scheduler cfq registered (default)
[    0.714510] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.723777] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.739698] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    0.747967] console [ttyO0] enabled, bootconsole disabled
[    0.747967] console [ttyO0] enabled, bootconsole disabled
[    0.762091] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1
[    0.772232] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP UART2
[    0.782654] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60) is a OMAP UART3
[    0.792624] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
[    0.802588] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP UART5
[    0.843181] brd: module loaded
[    0.865884] loop: module loaded
[    0.874171] Generic platform RAM MTD, (c) 2004 Simtec Electronics
[    0.886752] usbcore: registered new interface driver rt2800usb
[    0.893362] usbcore: registered new interface driver asix
[    0.899570] usbcore: registered new interface driver cdc_ether
[    0.906226] usbcore: registered new interface driver smsc95xx
[    0.912745] usbcore: registered new interface driver net1080
[    0.919220] usbcore: registered new interface driver cdc_subset
[    0.925972] usbcore: registered new interface driver zaurus
[    0.932386] usbcore: registered new interface driver cdc_ncm
[    0.940627] usbcore: registered new interface driver cdc_wdm
[    0.947182] usbcore: registered new interface driver usbtest
[    0.953609] i2c /dev entries driver
[    0.962424] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    0.975466] usbcore: registered new interface driver usbhid
[    0.981346] usbhid: USB HID core driver
[    0.986783] oprofile: no performance counters
[    0.993932] oprofile: using timer interrupt.
[    0.999224] TCP: cubic registered
[    1.002724] Initializing XFRM netlink socket
[    1.007408] NET: Registered protocol family 17
[    1.012203] NET: Registered protocol family 15
[    1.017496] Key type dns_resolver registered
[    1.022171] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    1.030376] ThumbEE CPU extension supported.
[    1.039576] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    1.052059] spansion,s29gl010p11t: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x002266 Chip ID 0x00223e
[    1.063590] Amd/Fujitsu Extended Query Table at 0x0040
[    1.069058]   Amd/Fujitsu Extended Query version 1.3.
[    1.074426] number of CFI chips: 1
[    1.078250] 7 ofpart partitions found on MTD device spansion,s29gl010p11t
[    1.085438] Creating 7 MTD partitions on "spansion,s29gl010p11t":
[    1.091869] 0x000000000000-0x0000000c0000 : "boot"
[    1.104959] 0x0000000c0000-0x0000000e0000 : "env1"
[    1.115074] 0x0000000e0000-0x000000100000 : "env2"
[    1.124888] 0x000000100000-0x000000500000 : "kernel"
[    1.134892] 0x000000500000-0x000001500000 : "rootfs"
[    1.145051] 0x000001500000-0x000004000000 : "user"
[    1.154950] 0x000004000000-0x000008000000 : "data"
[    1.170564] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.181724] gpiochip_find_base: found new base at 240
[    1.188394] gpiochip_add: registered GPIOs 240 to 255 on device: mcp23017
[    1.201011] DCDC1: at 1500 mV
[    1.206835] vdd_mpu: 925 <--> 1325 mV at 1100 mV
[    1.214128] vdd_core: 925 <--> 1150 mV at 1100 mV
[    1.221458] LDO1: at 1800 mV
[    1.226815] LDO2: at 3300 mV
[    1.232215] LDO3: at 1800 mV
[    1.237537] LDO4: at 3300 mV
[    1.242640] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    1.249346] at24 0-0053: 256 byte 24c02 EEPROM, writable, 8 bytes/write
[    1.260583] rtc-ds1307 0-0068: rtc core: registered ds1307 as rtc0
[    1.267223] rtc-ds1307 0-0068: 56 bytes nvram
[    1.333979] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    1.340425] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    1.350461] libphy: 4a101000.mdio: probed
[    1.354791] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    1.364453] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver SMSC LAN8710/LAN8720
[    1.374403] Detected MACID = c8:a0:30:83:91:be
[    1.382355] cpsw: Detected MACID = c8:a0:30:83:91:bf
[    1.391359] rtc-ds1307 0-0068: setting system clock to 2000-01-23 22:06:49 UTC (948665209)
[    3.010550] VFS: Mounted root (jffs2 filesystem) readonly on device 31:4.
[    3.019030] devtmpfs: mounted
[    3.022638] Freeing unused kernel memory: 200K (c0543000 - c0575000)

[-- Attachment #2: dotconfig --]
[-- Type: text/plain, Size: 59898 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_KEYSTONE is not set
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
CONFIG_MACH_OMAP_GENERIC=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_OMAP3430 is not set
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y
# CONFIG_SOC_AM43XX is not set

#
# OMAP Board Type
#
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OMAP3530_LV_SOM is not set
# CONFIG_MACH_OMAP3_TORPEDO is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_CRANEBOARD is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_TOUCHBOOK is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_NOKIA_RM680 is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
# CONFIG_MACH_OMAP_ZOOM3 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_CM_T3517 is not set
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_IGEP0030 is not set
# CONFIG_MACH_SBC3530 is not set
# CONFIG_MACH_OMAP_3630SDP is not set
# CONFIG_MACH_TI8168EVM is not set
# CONFIG_MACH_TI8148EVM is not set
# CONFIG_OMAP3_EMU is not set
# CONFIG_OMAP3_SDRC_AC_TIMING is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_STI is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set

#
# ST-Ericsson AB U300/U335 Platform
#

#
# ST-Ericsson Mobile Platform Products
#

#
# ST-Ericsson U300/U335 Feature Selections
#
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_VIRT_EXT=y
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
# CONFIG_PL310_ERRATA_753970 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
CONFIG_ICST=y
CONFIG_TI_PRIV_EDMA=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
# CONFIG_GENERIC_CPUFREQ_CPU0 is not set

#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5440_CPUFREQ is not set
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
CONFIG_ARM_OMAP2PLUS_CPUFREQ=y
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_NET_IP_TUNNEL is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
# CONFIG_ARM_CCI is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_PHYSMAP_COMPAT is not set
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PLATRAM=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_BCH_CONST_M=13
CONFIG_BCH_CONST_T=8
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_NAND_OMAP_BCH=y
CONFIG_MTD_NAND_OMAP_BCH8=y
# CONFIG_MTD_NAND_OMAP_BCH4 is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TI_DAVINCI_EMAC is not set
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
CONFIG_TI_CPSW=y
# CONFIG_TI_CPTS is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
# CONFIG_USB_NET_AX88179_178A is not set
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8187 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
CONFIG_RT2X00=y
# CONFIG_RT2500USB is not set
# CONFIG_RT73USB is not set
CONFIG_RT2800USB=y
CONFIG_RT2800USB_RT33XX=y
CONFIG_RT2800USB_RT35XX=y
# CONFIG_RT2800USB_RT53XX is not set
# CONFIG_RT2800USB_RT55XX is not set
# CONFIG_RT2800USB_UNKNOWN is not set
CONFIG_RT2800_LIB=y
CONFIG_RT2X00_LIB_USB=y
CONFIG_RT2X00_LIB=y
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_DEBUG is not set
# CONFIG_RTLWIFI is not set
# CONFIG_WL_TI is not set
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_SINGLE=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TWL4030 is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
CONFIG_GPIO_MCP23S08=y
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_TWL4030 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_RESET_VEXPRESS=y
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
CONFIG_MFD_TPS65217=y
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
# CONFIG_MFD_TWL4030_AUDIO is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_TI_ABB is not set
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_TEGRA_HOST1X is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FUSBH200_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_TWL4030 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_OMAP is not set
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_TI_EDMA=y
# CONFIG_PL330_DMA is not set
CONFIG_DMA_OMAP=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_ARM_ARCH_TIMER=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
CONFIG_JFFS2_CMODE_NONE=y
# CONFIG_JFFS2_CMODE_PRIORITY is not set
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
# CONFIG_UBIFS_FS_ZLIB is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_OMAP2PLUS_UART=y
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
# CONFIG_DEBUG_VEXPRESS_UART0_RS1 is not set
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
# CONFIG_DEBUG_OMAP2UART1 is not set
# CONFIG_DEBUG_OMAP2UART2 is not set
# CONFIG_DEBUG_OMAP2UART3 is not set
# CONFIG_DEBUG_OMAP3UART3 is not set
# CONFIG_DEBUG_OMAP4UART3 is not set
# CONFIG_DEBUG_OMAP3UART4 is not set
# CONFIG_DEBUG_OMAP4UART4 is not set
# CONFIG_DEBUG_TI81XXUART1 is not set
# CONFIG_DEBUG_TI81XXUART2 is not set
# CONFIG_DEBUG_TI81XXUART3 is not set
CONFIG_DEBUG_AM33XXUART1=y
# CONFIG_DEBUG_ZOOM_UART is not set
CONFIG_DEBUG_LL_INCLUDE="debug/omap2plus.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-04 13:25 ` Mark Jackson
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Jackson @ 2013-07-04 13:25 UTC (permalink / raw)
  To: linux-arm-kernel

Our custom AM335x board has been booting just fine under 3.10.0-rc4.

I've just done a git pull to update to 3.10 (now that it's released)
and the board now hangs.

Before I start trying to bisect the issue, does anyone have an clues ?

I've attached my dotconfig.

Cheers
Mark J.

<<<< BAD BOOT >>>>

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-05288-g526a1a9-dirty (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #260 Thu Jul 4 13:43:19 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c05d2c84, node_mem_map c0b06000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: earlyprintk debug console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 rootfstype=jffs2 root=/dev/mtdblock4 ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 247508K/261120K available (4372K kernel code, 334K rwdata, 1016K rodata, 202K init, 5305K bss, 13612K reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc054b4e4   (5390 kB)
[    0.000000]       .init : 0xc054c000 - 0xc057eb74   ( 203 kB)
[    0.000000]       .data : 0xc0580000 - 0xc05d38a0   ( 335 kB)
[    0.000000]        .bss : 0xc05d38a0 - 0xc0b01f08   (5306 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: timer1 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062349] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)
[    0.119097] pid_max: default: 32768 minimum: 301
[    0.124246] Security Framework initialized
[    0.128690] Mount-cache hash table entries: 512
[    0.146814] CPU: Testing write buffer coherency: ok
[    0.153481] Setting up static identity map for 0xc0426b20 - 0xc0426b78
[    0.164988] devtmpfs: initialized

<<<< GOOD BOOT >>>>

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.0-rc4-00172-gf31c62e-dirty (mpfj at mpfj-nanobone) (gcc version 4.6.3 (Buildroot 2013.02-dirty) ) #259 Thu Jul 4 11:05:23 BST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow AM335x NanoBone
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 65280
[    0.000000] free_area_init_node: node 0, pgdat c05c8a3c, node_mem_map c0afc000
[    0.000000]   Normal zone: 512 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 65280 pages, LIFO batch:15
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] AM335X ES1.0 (neon )
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64768
[    0.000000] Kernel command line: earlyprintk debug console=ttyO0,115200n8 noinitrd ip=off mem=256M rootwait=1 rootfstype=jffs2 root=/dev/mtdblock4 ignore_loglevel
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 255MB = 255MB total
[    0.000000] Memory: 247552k/247552k available, 14592k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]       .text : 0xc0008000 - 0xc054210c   (5353 kB)
[    0.000000]       .init : 0xc0543000 - 0xc05757ac   ( 202 kB)
[    0.000000]       .data : 0xc0576000 - 0xc05c9620   ( 334 kB)
[    0.000000]        .bss : 0xc05c9620 - 0xc0af7a88   (5306 kB)
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: timer2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 165191ms
[    0.000000] OMAP clocksource: timer1 at 26000000 Hz
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.062209] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624)
[    0.119227] pid_max: default: 32768 minimum: 301
[    0.124383] Security Framework initialized
[    0.128826] Mount-cache hash table entries: 512
[    0.145982] CPU: Testing write buffer coherency: ok
[    0.152707] Setting up static identity map for 0xc041ed88 - 0xc041ede0
[    0.164118] devtmpfs: initialized
[    0.173232] ttyO0 used as console in debug mode: uart0 clocks will not be gated
[    0.242012] pinctrl core: initialized pinctrl subsystem
[    0.252653] regulator-dummy: no parameters
[    0.260174] NET: Registered protocol family 16
[    0.265723] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.295484] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[    0.303439] OMAP GPIO hardware version 0.1
[    0.310567] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[    0.320495] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[    0.330479] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[    0.356857] omap-gpmc 50000000.gpmc: could not find pctldev for node /pinmux at 44e10800/gpmc_pins, deferring probe
[    0.367516] platform 50000000.gpmc: Driver omap-gpmc requests probe deferral
[    0.375643] No ATAGs?
[    0.377853] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.385002] cpsw.0: No hwaddr in dt. Using c8:a0:30:83:91:be from efuse
[    0.391981] cpsw.1: No hwaddr in dt. Using c8:a0:30:83:91:bf from efuse
[    0.449213] bio: create slab <bio-0> at 0
[    0.463822] usbcore: registered new interface driver usbfs
[    0.470140] usbcore: registered new interface driver hub
[    0.476512] usbcore: registered new device driver usb
[    0.482966] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux at 44e10800/i2c0_pins, deferring probe
[    0.493433] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    0.510569] cfg80211: Calling CRDA to update world regulatory domain
[    0.519405] Switching to clocksource timer1
[    0.585009] NET: Registered protocol family 2
[    0.591523] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.599211] TCP bind hash table entries: 2048 (order: 4, 73728 bytes)
[    0.607185] TCP: Hash tables configured (established 2048 bind 2048)
[    0.614144] TCP: reno registered
[    0.617577] UDP hash table entries: 256 (order: 2, 20480 bytes)
[    0.624133] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[    0.632359] NET: Registered protocol family 1
[    0.638659] RPC: Registered named UNIX socket transport module.
[    0.644927] RPC: Registered udp transport module.
[    0.649858] RPC: Registered tcp transport module.
[    0.654821] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.662640] NetWinder Floating Point Emulator V0.97 (double precision)
[    0.683580] jffs2: version 2.2. ? 2001-2006 Red Hat, Inc.
[    0.689959] msgmni has been set to 483
[    0.699227] io scheduler noop registered
[    0.703370] io scheduler deadline registered
[    0.707997] io scheduler cfq registered (default)
[    0.714510] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.723777] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.739698] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[    0.747967] console [ttyO0] enabled, bootconsole disabled
[    0.747967] console [ttyO0] enabled, bootconsole disabled
[    0.762091] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1
[    0.772232] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90) is a OMAP UART2
[    0.782654] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60) is a OMAP UART3
[    0.792624] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61) is a OMAP UART4
[    0.802588] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62) is a OMAP UART5
[    0.843181] brd: module loaded
[    0.865884] loop: module loaded
[    0.874171] Generic platform RAM MTD, (c) 2004 Simtec Electronics
[    0.886752] usbcore: registered new interface driver rt2800usb
[    0.893362] usbcore: registered new interface driver asix
[    0.899570] usbcore: registered new interface driver cdc_ether
[    0.906226] usbcore: registered new interface driver smsc95xx
[    0.912745] usbcore: registered new interface driver net1080
[    0.919220] usbcore: registered new interface driver cdc_subset
[    0.925972] usbcore: registered new interface driver zaurus
[    0.932386] usbcore: registered new interface driver cdc_ncm
[    0.940627] usbcore: registered new interface driver cdc_wdm
[    0.947182] usbcore: registered new interface driver usbtest
[    0.953609] i2c /dev entries driver
[    0.962424] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    0.975466] usbcore: registered new interface driver usbhid
[    0.981346] usbhid: USB HID core driver
[    0.986783] oprofile: no performance counters
[    0.993932] oprofile: using timer interrupt.
[    0.999224] TCP: cubic registered
[    1.002724] Initializing XFRM netlink socket
[    1.007408] NET: Registered protocol family 17
[    1.012203] NET: Registered protocol family 15
[    1.017496] Key type dns_resolver registered
[    1.022171] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    1.030376] ThumbEE CPU extension supported.
[    1.039576] omap-gpmc 50000000.gpmc: GPMC revision 6.0
[    1.052059] spansion,s29gl010p11t: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x002266 Chip ID 0x00223e
[    1.063590] Amd/Fujitsu Extended Query Table at 0x0040
[    1.069058]   Amd/Fujitsu Extended Query version 1.3.
[    1.074426] number of CFI chips: 1
[    1.078250] 7 ofpart partitions found on MTD device spansion,s29gl010p11t
[    1.085438] Creating 7 MTD partitions on "spansion,s29gl010p11t":
[    1.091869] 0x000000000000-0x0000000c0000 : "boot"
[    1.104959] 0x0000000c0000-0x0000000e0000 : "env1"
[    1.115074] 0x0000000e0000-0x000000100000 : "env2"
[    1.124888] 0x000000100000-0x000000500000 : "kernel"
[    1.134892] 0x000000500000-0x000001500000 : "rootfs"
[    1.145051] 0x000001500000-0x000004000000 : "user"
[    1.154950] 0x000004000000-0x000008000000 : "data"
[    1.170564] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    1.181724] gpiochip_find_base: found new base at 240
[    1.188394] gpiochip_add: registered GPIOs 240 to 255 on device: mcp23017
[    1.201011] DCDC1: at 1500 mV
[    1.206835] vdd_mpu: 925 <--> 1325 mV at 1100 mV
[    1.214128] vdd_core: 925 <--> 1150 mV at 1100 mV
[    1.221458] LDO1: at 1800 mV
[    1.226815] LDO2: at 3300 mV
[    1.232215] LDO3: at 1800 mV
[    1.237537] LDO4: at 3300 mV
[    1.242640] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    1.249346] at24 0-0053: 256 byte 24c02 EEPROM, writable, 8 bytes/write
[    1.260583] rtc-ds1307 0-0068: rtc core: registered ds1307 as rtc0
[    1.267223] rtc-ds1307 0-0068: 56 bytes nvram
[    1.333979] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    1.340425] davinci_mdio 4a101000.mdio: detected phy mask fffffffc
[    1.350461] libphy: 4a101000.mdio: probed
[    1.354791] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    1.364453] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver SMSC LAN8710/LAN8720
[    1.374403] Detected MACID = c8:a0:30:83:91:be
[    1.382355] cpsw: Detected MACID = c8:a0:30:83:91:bf
[    1.391359] rtc-ds1307 0-0068: setting system clock to 2000-01-23 22:06:49 UTC (948665209)
[    3.010550] VFS: Mounted root (jffs2 filesystem) readonly on device 31:4.
[    3.019030] devtmpfs: mounted
[    3.022638] Freeing unused kernel memory: 200K (c0543000 - c0575000)
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_NO_IOPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_ARCH_HAS_BANDGAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_KEYSTONE is not set
# CONFIG_ARCH_MXC is not set

#
# TI OMAP Common Features
#

#
# OMAP Feature Selections
#
CONFIG_OMAP_RESET_CLOCKS=y
CONFIG_OMAP_MUX=y
CONFIG_OMAP_MUX_DEBUG=y
CONFIG_OMAP_MUX_WARNINGS=y
CONFIG_OMAP_32K_TIMER=y
# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set
CONFIG_OMAP_DM_TIMER=y
CONFIG_OMAP_PM_NOOP=y
CONFIG_MACH_OMAP_GENERIC=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP2PLUS=y

#
# TI OMAP2/3/4 Specific Features
#
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_SOC_HAS_OMAP2_SDRC=y
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_OMAP3430 is not set
CONFIG_SOC_TI81XX=y
CONFIG_SOC_AM33XX=y
# CONFIG_SOC_AM43XX is not set

#
# OMAP Board Type
#
# CONFIG_MACH_OMAP3_BEAGLE is not set
# CONFIG_MACH_DEVKIT8000 is not set
# CONFIG_MACH_OMAP_LDP is not set
# CONFIG_MACH_OMAP3530_LV_SOM is not set
# CONFIG_MACH_OMAP3_TORPEDO is not set
# CONFIG_MACH_OVERO is not set
# CONFIG_MACH_OMAP3EVM is not set
# CONFIG_MACH_OMAP3517EVM is not set
# CONFIG_MACH_CRANEBOARD is not set
# CONFIG_MACH_OMAP3_PANDORA is not set
# CONFIG_MACH_TOUCHBOOK is not set
# CONFIG_MACH_OMAP_3430SDP is not set
# CONFIG_MACH_NOKIA_RM680 is not set
# CONFIG_MACH_NOKIA_RX51 is not set
# CONFIG_MACH_OMAP_ZOOM2 is not set
# CONFIG_MACH_OMAP_ZOOM3 is not set
# CONFIG_MACH_CM_T35 is not set
# CONFIG_MACH_CM_T3517 is not set
# CONFIG_MACH_IGEP0020 is not set
# CONFIG_MACH_IGEP0030 is not set
# CONFIG_MACH_SBC3530 is not set
# CONFIG_MACH_OMAP_3630SDP is not set
# CONFIG_MACH_TI8168EVM is not set
# CONFIG_MACH_TI8148EVM is not set
# CONFIG_OMAP3_EMU is not set
# CONFIG_OMAP3_SDRC_AC_TIMING is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_STI is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set

#
# ST-Ericsson AB U300/U335 Platform
#

#
# ST-Ericsson Mobile Platform Products
#

#
# ST-Ericsson U300/U335 Feature Selections
#
# CONFIG_ARCH_U8500 is not set
CONFIG_ARCH_VEXPRESS=y

#
# Versatile Express platform type
#
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
# CONFIG_ARCH_VEXPRESS_CA9X4 is not set
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
CONFIG_ARM_THUMBEE=y
CONFIG_ARM_VIRT_EXT=y
# CONFIG_SWP_EMULATE is not set
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
CONFIG_PL310_ERRATA_727915=y
# CONFIG_PL310_ERRATA_753970 is not set
# CONFIG_ARM_ERRATA_754322 is not set
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
CONFIG_ICST=y
CONFIG_TI_PRIV_EDMA=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
# CONFIG_SMP is not set
CONFIG_HAVE_ARM_ARCH_TIMER=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_HW_PERF_EVENTS=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
CONFIG_KEXEC=y
CONFIG_ATAGS_PROC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
# CONFIG_GENERIC_CPUFREQ_CPU0 is not set

#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5440_CPUFREQ is not set
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
CONFIG_ARM_OMAP2PLUS_CPUFREQ=y
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_NET_IP_TUNNEL is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_BQL=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_SOC_BUS=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_OMAP_OCP2SCP is not set
CONFIG_OMAP_INTERCONNECT=y
# CONFIG_ARM_CCI is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_PHYSMAP_COMPAT is not set
CONFIG_MTD_PHYSMAP_OF=y
CONFIG_MTD_PLATRAM=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=y

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_BCH_CONST_M=13
CONFIG_BCH_CONST_T=8
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_OMAP2=y
CONFIG_MTD_NAND_OMAP_BCH=y
CONFIG_MTD_NAND_OMAP_BCH8=y
# CONFIG_MTD_NAND_OMAP_BCH4 is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TI_DAVINCI_EMAC is not set
CONFIG_TI_DAVINCI_MDIO=y
CONFIG_TI_DAVINCI_CPDMA=y
CONFIG_TI_CPSW=y
# CONFIG_TI_CPTS is not set
# CONFIG_NET_VENDOR_WIZNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
CONFIG_SMSC_PHY=y
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
# CONFIG_USB_NET_AX88179_178A is not set
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
CONFIG_USB_NET_SMSC95XX=y
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=y
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_USB_NET_ZAURUS=y
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_USB_VL600 is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8187 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
CONFIG_RT2X00=y
# CONFIG_RT2500USB is not set
# CONFIG_RT73USB is not set
CONFIG_RT2800USB=y
CONFIG_RT2800USB_RT33XX=y
CONFIG_RT2800USB_RT35XX=y
# CONFIG_RT2800USB_RT53XX is not set
# CONFIG_RT2800USB_RT55XX is not set
# CONFIG_RT2800USB_UNKNOWN is not set
CONFIG_RT2800_LIB=y
CONFIG_RT2X00_LIB_USB=y
CONFIG_RT2X00_LIB=y
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
# CONFIG_RT2X00_DEBUG is not set
# CONFIG_RTLWIFI is not set
# CONFIG_WL_TI is not set
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_OF_PLATFORM is not set
CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_OMAP=y
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
CONFIG_SPI_OMAP24XX=y
# CONFIG_SPI_PL022 is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set

#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_SINGLE=y
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_TWL4030 is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
CONFIG_GPIO_MCP23S08=y
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_TWL4030 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_RESET_VEXPRESS=y
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
CONFIG_OMAP_WATCHDOG=y
CONFIG_TWL4030_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
CONFIG_MFD_TPS65217=y
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
CONFIG_TWL4030_CORE=y
# CONFIG_TWL4030_MADC is not set
CONFIG_TWL4030_POWER=y
# CONFIG_MFD_TWL4030_AUDIO is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_VEXPRESS_CONFIG=y
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_REGULATOR_TWL4030=y
# CONFIG_REGULATOR_TI_ABB is not set
# CONFIG_REGULATOR_VEXPRESS is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_TEGRA_HOST1X is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_OMAP2_DSS is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
# CONFIG_USB_EHCI_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FUSBH200_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_WDM=y
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=y
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=y
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_TWL4030 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_OMAP is not set
# CONFIG_RTC_DRV_PL030 is not set
# CONFIG_RTC_DRV_PL031 is not set
# CONFIG_RTC_DRV_SNVS is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_AMBA_PL08X is not set
# CONFIG_DW_DMAC is not set
# CONFIG_TIMB_DMA is not set
CONFIG_TI_EDMA=y
# CONFIG_PL330_DMA is not set
CONFIG_DMA_OMAP=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_DEBUG is not set
CONFIG_COMMON_CLK_VERSATILE=y
# CONFIG_COMMON_CLK_SI5351 is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_ARM_ARCH_TIMER=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
# CONFIG_OMAP_IOMMU is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_FS_POSIX_ACL is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_RTIME=y
CONFIG_JFFS2_RUBIN=y
CONFIG_JFFS2_CMODE_NONE=y
# CONFIG_JFFS2_CMODE_PRIORITY is not set
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_ADVANCED_COMPR=y
CONFIG_UBIFS_FS_LZO=y
# CONFIG_UBIFS_FS_ZLIB is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_OMAP2PLUS_UART=y
# CONFIG_DEBUG_VEXPRESS_UART0_DETECT is not set
# CONFIG_DEBUG_VEXPRESS_UART0_CA9 is not set
# CONFIG_DEBUG_VEXPRESS_UART0_RS1 is not set
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
# CONFIG_DEBUG_OMAP2UART1 is not set
# CONFIG_DEBUG_OMAP2UART2 is not set
# CONFIG_DEBUG_OMAP2UART3 is not set
# CONFIG_DEBUG_OMAP3UART3 is not set
# CONFIG_DEBUG_OMAP4UART3 is not set
# CONFIG_DEBUG_OMAP3UART4 is not set
# CONFIG_DEBUG_OMAP4UART4 is not set
# CONFIG_DEBUG_TI81XXUART1 is not set
# CONFIG_DEBUG_TI81XXUART2 is not set
# CONFIG_DEBUG_TI81XXUART3 is not set
CONFIG_DEBUG_AM33XXUART1=y
# CONFIG_DEBUG_ZOOM_UART is not set
CONFIG_DEBUG_LL_INCLUDE="debug/omap2plus.S"
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
CONFIG_EARLY_PRINTK=y
# CONFIG_OC_ETM is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_ARM is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_BCH=y
CONFIG_BCH_CONST_PARAMS=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-04 13:25 ` Mark Jackson
@ 2013-07-04 15:14   ` Mark Jackson
  -1 siblings, 0 replies; 96+ messages in thread
From: Mark Jackson @ 2013-07-04 15:14 UTC (permalink / raw)
  To: linux-omap, Tony Lindgren; +Cc: linux-arm-kernel

On 04/07/13 14:25, Mark Jackson wrote:
> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> 
> I've just done a git pull to update to 3.10 (now that it's released)
> and the board now hangs.
> 
> Before I start trying to bisect the issue, does anyone have an clues ?

Okay ... I've now bisected it to:-

a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
commit a630fbfbb1beeffc5bbe542a7986bf2068874633
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jun 10 07:39:09 2013 -0700

    serial: omap: Fix device tree based PM runtime
    
    In the runtime_suspend function pdata is not being used, and
    also blocks the function in device tree based booting. Fix it
    by removing the unused pdata from the runtime_suspend function.
    
    Further, context loss count is not being passed in pdata, so
    let's just reinitialize the port every time for those case.
    This can be further optimized later on for the device tree
    case by adding detection for the hardware state and possibly
    by adding a driver specific autosuspend timeout.
    
    And doing this, we can then make the related dev_err into a
    dev_dbg message instead of an error.
    
    In order for the wake-up events to work, we also need to set
    autosuspend_timeout to -1 if 0, and also device_init_wakeup()
    as that's not being done by the platform init code for the
    device tree case.
    
    Note that this does not affect legacy booting, and in fact
    might make it work for the cases where the context loss info
    is not being passed in pdata.
    
    Thanks to Kevin Hilman <khilman@linaro.org> for debugging
    and suggesting fixes for the autosuspend_timeout and
    device_init_wakeup() related initializiation.
    
    Reviewed-by: Kevin Hilman <khilman@linaro.org>
    Tested-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 38900a5a2ed6dfeb812d93bf1918725021298884 a38d37777dcd46276dc27b87157fd0b1e292804c M	drivers



^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-04 15:14   ` Mark Jackson
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Jackson @ 2013-07-04 15:14 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/07/13 14:25, Mark Jackson wrote:
> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> 
> I've just done a git pull to update to 3.10 (now that it's released)
> and the board now hangs.
> 
> Before I start trying to bisect the issue, does anyone have an clues ?

Okay ... I've now bisected it to:-

a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
commit a630fbfbb1beeffc5bbe542a7986bf2068874633
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Jun 10 07:39:09 2013 -0700

    serial: omap: Fix device tree based PM runtime
    
    In the runtime_suspend function pdata is not being used, and
    also blocks the function in device tree based booting. Fix it
    by removing the unused pdata from the runtime_suspend function.
    
    Further, context loss count is not being passed in pdata, so
    let's just reinitialize the port every time for those case.
    This can be further optimized later on for the device tree
    case by adding detection for the hardware state and possibly
    by adding a driver specific autosuspend timeout.
    
    And doing this, we can then make the related dev_err into a
    dev_dbg message instead of an error.
    
    In order for the wake-up events to work, we also need to set
    autosuspend_timeout to -1 if 0, and also device_init_wakeup()
    as that's not being done by the platform init code for the
    device tree case.
    
    Note that this does not affect legacy booting, and in fact
    might make it work for the cases where the context loss info
    is not being passed in pdata.
    
    Thanks to Kevin Hilman <khilman@linaro.org> for debugging
    and suggesting fixes for the autosuspend_timeout and
    device_init_wakeup() related initializiation.
    
    Reviewed-by: Kevin Hilman <khilman@linaro.org>
    Tested-by: Kevin Hilman <khilman@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 38900a5a2ed6dfeb812d93bf1918725021298884 a38d37777dcd46276dc27b87157fd0b1e292804c M	drivers

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-04 15:14   ` Mark Jackson
@ 2013-07-04 16:00     ` Mark Jackson
  -1 siblings, 0 replies; 96+ messages in thread
From: Mark Jackson @ 2013-07-04 16:00 UTC (permalink / raw)
  To: linux-omap, Tony Lindgren; +Cc: linux-arm-kernel

On 04/07/13 16:14, Mark Jackson wrote:
> On 04/07/13 14:25, Mark Jackson wrote:
>> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
>>
>> I've just done a git pull to update to 3.10 (now that it's released)
>> and the board now hangs.
>>
>> Before I start trying to bisect the issue, does anyone have an clues ?
> 
> Okay ... I've now bisected it to:-
> 
> a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> Author: Tony Lindgren <tony@atomide.com>
> Date:   Mon Jun 10 07:39:09 2013 -0700
> 
>     serial: omap: Fix device tree based PM runtime

However, reverting the commit does *not* fix the issue, weird !!

But I have now tested:-

v3.10-rc4     -> works
v3.10-rc5     -> works
v3.10-rc6     -> works
v3.10-rc7     -> works
v3.10         -> works
origin/master -> hangs

Any ideas ?

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-04 16:00     ` Mark Jackson
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Jackson @ 2013-07-04 16:00 UTC (permalink / raw)
  To: linux-arm-kernel

On 04/07/13 16:14, Mark Jackson wrote:
> On 04/07/13 14:25, Mark Jackson wrote:
>> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
>>
>> I've just done a git pull to update to 3.10 (now that it's released)
>> and the board now hangs.
>>
>> Before I start trying to bisect the issue, does anyone have an clues ?
> 
> Okay ... I've now bisected it to:-
> 
> a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> Author: Tony Lindgren <tony@atomide.com>
> Date:   Mon Jun 10 07:39:09 2013 -0700
> 
>     serial: omap: Fix device tree based PM runtime

However, reverting the commit does *not* fix the issue, weird !!

But I have now tested:-

v3.10-rc4     -> works
v3.10-rc5     -> works
v3.10-rc6     -> works
v3.10-rc7     -> works
v3.10         -> works
origin/master -> hangs

Any ideas ?

^ permalink raw reply	[flat|nested] 96+ messages in thread

* RE: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-04 16:00     ` Mark Jackson
@ 2013-07-05  8:11       ` Bedia, Vaibhav
  -1 siblings, 0 replies; 96+ messages in thread
From: Bedia, Vaibhav @ 2013-07-05  8:11 UTC (permalink / raw)
  To: Mark Jackson, linux-omap, Tony Lindgren; +Cc: linux-arm-kernel

On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> On 04/07/13 16:14, Mark Jackson wrote:
> > On 04/07/13 14:25, Mark Jackson wrote:
> >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> >>
> >> I've just done a git pull to update to 3.10 (now that it's released)
> >> and the board now hangs.
> >>
> >> Before I start trying to bisect the issue, does anyone have an clues ?
> > 
> > Okay ... I've now bisected it to:-
> > 
> > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > Author: Tony Lindgren <tony@atomide.com>
> > Date:   Mon Jun 10 07:39:09 2013 -0700
> > 
> >     serial: omap: Fix device tree based PM runtime
> 
> However, reverting the commit does *not* fix the issue, weird !!
> 
> But I have now tested:-
> 
> v3.10-rc4     -> works
> v3.10-rc5     -> works
> v3.10-rc6     -> works
> v3.10-rc7     -> works
> v3.10         -> works
> origin/master -> hangs
> 
> Any ideas ?

I just checked the behavior on my AM335x-EVM. Current mainline boots fine
provided I don't use earlyprintk.  The offending patch [1] in this case is the one
that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
also results in the console UART getting reset and idled during bootup and that's where
the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
the system booting fine. 

I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
omap_serial_early_init() to get earlyprintk working again.

Regards,
Vaibhav B.

[1] http://www.spinics.net/lists/linux-omap/msg91825.html


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-05  8:11       ` Bedia, Vaibhav
  0 siblings, 0 replies; 96+ messages in thread
From: Bedia, Vaibhav @ 2013-07-05  8:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> On 04/07/13 16:14, Mark Jackson wrote:
> > On 04/07/13 14:25, Mark Jackson wrote:
> >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> >>
> >> I've just done a git pull to update to 3.10 (now that it's released)
> >> and the board now hangs.
> >>
> >> Before I start trying to bisect the issue, does anyone have an clues ?
> > 
> > Okay ... I've now bisected it to:-
> > 
> > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > Author: Tony Lindgren <tony@atomide.com>
> > Date:   Mon Jun 10 07:39:09 2013 -0700
> > 
> >     serial: omap: Fix device tree based PM runtime
> 
> However, reverting the commit does *not* fix the issue, weird !!
> 
> But I have now tested:-
> 
> v3.10-rc4     -> works
> v3.10-rc5     -> works
> v3.10-rc6     -> works
> v3.10-rc7     -> works
> v3.10         -> works
> origin/master -> hangs
> 
> Any ideas ?

I just checked the behavior on my AM335x-EVM. Current mainline boots fine
provided I don't use earlyprintk.  The offending patch [1] in this case is the one
that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
also results in the console UART getting reset and idled during bootup and that's where
the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
the system booting fine. 

I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
omap_serial_early_init() to get earlyprintk working again.

Regards,
Vaibhav B.

[1] http://www.spinics.net/lists/linux-omap/msg91825.html

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-05  8:11       ` Bedia, Vaibhav
@ 2013-07-05 11:59         ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-05 11:59 UTC (permalink / raw)
  To: Bedia, Vaibhav; +Cc: Mark Jackson, linux-omap, linux-arm-kernel

* Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> > On 04/07/13 16:14, Mark Jackson wrote:
> > > On 04/07/13 14:25, Mark Jackson wrote:
> > >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> > >>
> > >> I've just done a git pull to update to 3.10 (now that it's released)
> > >> and the board now hangs.
> > >>
> > >> Before I start trying to bisect the issue, does anyone have an clues ?
> > > 
> > > Okay ... I've now bisected it to:-
> > > 
> > > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > > Author: Tony Lindgren <tony@atomide.com>
> > > Date:   Mon Jun 10 07:39:09 2013 -0700
> > > 
> > >     serial: omap: Fix device tree based PM runtime
> > 
> > However, reverting the commit does *not* fix the issue, weird !!
> > 
> > But I have now tested:-
> > 
> > v3.10-rc4     -> works
> > v3.10-rc5     -> works
> > v3.10-rc6     -> works
> > v3.10-rc7     -> works
> > v3.10         -> works
> > origin/master -> hangs
> > 
> > Any ideas ?
> 
> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> also results in the console UART getting reset and idled during bootup and that's where
> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> the system booting fine. 
> 
> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> omap_serial_early_init() to get earlyprintk working again.

Hmm nothing should get idled while earlyprintk is running, and then when the
serial driver kicks in it should not idle anything by default. And for DT based
booting we should not have mach-omap2/serial.c initialize anything.

I wonder if this is because the timeouts get now initialized to 0 instead
of -1 for the serial driver?

Regards,

Tony
 
> [1] http://www.spinics.net/lists/linux-omap/msg91825.html
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-05 11:59         ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-05 11:59 UTC (permalink / raw)
  To: linux-arm-kernel

* Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> On Thu, Jul 04, 2013 at 21:30:14, Mark Jackson wrote:
> > On 04/07/13 16:14, Mark Jackson wrote:
> > > On 04/07/13 14:25, Mark Jackson wrote:
> > >> Our custom AM335x board has been booting just fine under 3.10.0-rc4.
> > >>
> > >> I've just done a git pull to update to 3.10 (now that it's released)
> > >> and the board now hangs.
> > >>
> > >> Before I start trying to bisect the issue, does anyone have an clues ?
> > > 
> > > Okay ... I've now bisected it to:-
> > > 
> > > a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit
> > > commit a630fbfbb1beeffc5bbe542a7986bf2068874633
> > > Author: Tony Lindgren <tony@atomide.com>
> > > Date:   Mon Jun 10 07:39:09 2013 -0700
> > > 
> > >     serial: omap: Fix device tree based PM runtime
> > 
> > However, reverting the commit does *not* fix the issue, weird !!
> > 
> > But I have now tested:-
> > 
> > v3.10-rc4     -> works
> > v3.10-rc5     -> works
> > v3.10-rc6     -> works
> > v3.10-rc7     -> works
> > v3.10         -> works
> > origin/master -> hangs
> > 
> > Any ideas ?
> 
> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> also results in the console UART getting reset and idled during bootup and that's where
> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> the system booting fine. 
> 
> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> omap_serial_early_init() to get earlyprintk working again.

Hmm nothing should get idled while earlyprintk is running, and then when the
serial driver kicks in it should not idle anything by default. And for DT based
booting we should not have mach-omap2/serial.c initialize anything.

I wonder if this is because the timeouts get now initialized to 0 instead
of -1 for the serial driver?

Regards,

Tony
 
> [1] http://www.spinics.net/lists/linux-omap/msg91825.html
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* RE: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-05 11:59         ` Tony Lindgren
@ 2013-07-05 13:20           ` Bedia, Vaibhav
  -1 siblings, 0 replies; 96+ messages in thread
From: Bedia, Vaibhav @ 2013-07-05 13:20 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: Mark Jackson, linux-omap, linux-arm-kernel

Hi Tony,

On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > 
> > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > also results in the console UART getting reset and idled during bootup and that's where
> > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > the system booting fine. 
> > 
> > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > omap_serial_early_init() to get earlyprintk working again.
> 
> Hmm nothing should get idled while earlyprintk is running, and then when the
> serial driver kicks in it should not idle anything by default. And for DT based
> booting we should not have mach-omap2/serial.c initialize anything.
> 

If I add in the HWMOD flags without any reverts I get to the point where the serial driver
comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
just like Mark reported.

> I wonder if this is because the timeouts get now initialized to 0 instead
> of -1 for the serial driver?
> 

You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.

Regards,
Vaibhav

===
[1]

[    0.000000] Booting Linux on physical CPU 0x0
<...>
[    0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS).
[    0.196711] CPU: All CPU(s) started in SVC mode.
[    0.205580] devtmpfs: initialized
<stops here if booted with earlyprintk>

[2]
[    0.000000] Booting Linux on physical CPU 0x0
<...>
[    1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
<stops here if booted with earlyprintk>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-05 13:20           ` Bedia, Vaibhav
  0 siblings, 0 replies; 96+ messages in thread
From: Bedia, Vaibhav @ 2013-07-05 13:20 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Tony,

On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > 
> > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > also results in the console UART getting reset and idled during bootup and that's where
> > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > the system booting fine. 
> > 
> > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > omap_serial_early_init() to get earlyprintk working again.
> 
> Hmm nothing should get idled while earlyprintk is running, and then when the
> serial driver kicks in it should not idle anything by default. And for DT based
> booting we should not have mach-omap2/serial.c initialize anything.
> 

If I add in the HWMOD flags without any reverts I get to the point where the serial driver
comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
just like Mark reported.

> I wonder if this is because the timeouts get now initialized to 0 instead
> of -1 for the serial driver?
> 

You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.

Regards,
Vaibhav

===
[1]

[    0.000000] Booting Linux on physical CPU 0x0
<...>
[    0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS).
[    0.196711] CPU: All CPU(s) started in SVC mode.
[    0.205580] devtmpfs: initialized
<stops here if booted with earlyprintk>

[2]
[    0.000000] Booting Linux on physical CPU 0x0
<...>
[    1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
<stops here if booted with earlyprintk>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* RE: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-05 13:20           ` Bedia, Vaibhav
@ 2013-07-05 13:31             ` Bedia, Vaibhav
  -1 siblings, 0 replies; 96+ messages in thread
From: Bedia, Vaibhav @ 2013-07-05 13:31 UTC (permalink / raw)
  To: Bedia, Vaibhav, Tony Lindgren; +Cc: Mark Jackson, linux-omap, linux-arm-kernel

On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> Hi Tony,
> 
> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > > 
> > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > also results in the console UART getting reset and idled during bootup and that's where
> > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > the system booting fine. 
> > > 
> > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > omap_serial_early_init() to get earlyprintk working again.
> > 
> > Hmm nothing should get idled while earlyprintk is running, and then when the
> > serial driver kicks in it should not idle anything by default. And for DT based
> > booting we should not have mach-omap2/serial.c initialize anything.
> > 
> 
> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> just like Mark reported.
> 

Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.

> > I wonder if this is because the timeouts get now initialized to 0 instead
> > of -1 for the serial driver?
> > 
> 
> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> 
> Regards,
> Vaibhav
> 
> ===
> [1]
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> <...>
> [    0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS).
> [    0.196711] CPU: All CPU(s) started in SVC mode.
> [    0.205580] devtmpfs: initialized
> <stops here if booted with earlyprintk>
> 
> [2]
> [    0.000000] Booting Linux on physical CPU 0x0
> <...>
> [    1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
> [    1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> <stops here if booted with earlyprintk>
> --
> 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] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-05 13:31             ` Bedia, Vaibhav
  0 siblings, 0 replies; 96+ messages in thread
From: Bedia, Vaibhav @ 2013-07-05 13:31 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> Hi Tony,
> 
> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > > 
> > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > also results in the console UART getting reset and idled during bootup and that's where
> > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > the system booting fine. 
> > > 
> > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > omap_serial_early_init() to get earlyprintk working again.
> > 
> > Hmm nothing should get idled while earlyprintk is running, and then when the
> > serial driver kicks in it should not idle anything by default. And for DT based
> > booting we should not have mach-omap2/serial.c initialize anything.
> > 
> 
> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> just like Mark reported.
> 

Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.

> > I wonder if this is because the timeouts get now initialized to 0 instead
> > of -1 for the serial driver?
> > 
> 
> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> 
> Regards,
> Vaibhav
> 
> ===
> [1]
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> <...>
> [    0.190107] SMP: Total of 1 processors activated (363.72 BogoMIPS).
> [    0.196711] CPU: All CPU(s) started in SVC mode.
> [    0.205580] devtmpfs: initialized
> <stops here if booted with earlyprintk>
> 
> [2]
> [    0.000000] Booting Linux on physical CPU 0x0
> <...>
> [    1.453364] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
> [    1.467121] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> <stops here if booted with earlyprintk>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-05 13:31             ` Bedia, Vaibhav
@ 2013-07-08 11:25               ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-08 11:25 UTC (permalink / raw)
  To: Bedia, Vaibhav; +Cc: Mark Jackson, linux-omap, linux-arm-kernel

* Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> > Hi Tony,
> > 
> > On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > > > 
> > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > > also results in the console UART getting reset and idled during bootup and that's where
> > > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > > the system booting fine. 
> > > > 
> > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > > omap_serial_early_init() to get earlyprintk working again.
> > > 
> > > Hmm nothing should get idled while earlyprintk is running, and then when the
> > > serial driver kicks in it should not idle anything by default. And for DT based
> > > booting we should not have mach-omap2/serial.c initialize anything.
> > > 
> > 
> > If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> > comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> > just like Mark reported.
> > 
> 
> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.

It sounds like something needs to be fixed for am33xx as omap3 and omap4
won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
be needed at all for am33xx, and the bug is somewhere else.
 
> > > I wonder if this is because the timeouts get now initialized to 0 instead
> > > of -1 for the serial driver?
> > > 
> > 
> > You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> > am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.

OK

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 11:25               ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-08 11:25 UTC (permalink / raw)
  To: linux-arm-kernel

* Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> > Hi Tony,
> > 
> > On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > > > 
> > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > > also results in the console UART getting reset and idled during bootup and that's where
> > > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > > the system booting fine. 
> > > > 
> > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > > omap_serial_early_init() to get earlyprintk working again.
> > > 
> > > Hmm nothing should get idled while earlyprintk is running, and then when the
> > > serial driver kicks in it should not idle anything by default. And for DT based
> > > booting we should not have mach-omap2/serial.c initialize anything.
> > > 
> > 
> > If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> > comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> > just like Mark reported.
> > 
> 
> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.

It sounds like something needs to be fixed for am33xx as omap3 and omap4
won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
be needed at all for am33xx, and the bug is somewhere else.
 
> > > I wonder if this is because the timeouts get now initialized to 0 instead
> > > of -1 for the serial driver?
> > > 
> > 
> > You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> > am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.

OK

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 11:25               ` Tony Lindgren
@ 2013-07-08 12:16                 ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-08 12:16 UTC (permalink / raw)
  To: Bedia, Vaibhav; +Cc: Mark Jackson, linux-omap, linux-arm-kernel

* Tony Lindgren <tony@atomide.com> [130708 04:32]:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
> > On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> > > Hi Tony,
> > > 
> > > On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > > > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > > > > 
> > > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > > > also results in the console UART getting reset and idled during bootup and that's where
> > > > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > > > the system booting fine. 
> > > > > 
> > > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > > > omap_serial_early_init() to get earlyprintk working again.
> > > > 
> > > > Hmm nothing should get idled while earlyprintk is running, and then when the
> > > > serial driver kicks in it should not idle anything by default. And for DT based
> > > > booting we should not have mach-omap2/serial.c initialize anything.
> > > > 
> > > 
> > > If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> > > comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> > > just like Mark reported.
> > > 
> > 
> > Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> 
> It sounds like something needs to be fixed for am33xx as omap3 and omap4
> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> be needed at all for am33xx, and the bug is somewhere else.

Oops, sorry correction: I'm seeing it, I did not have console=ttyO
earlier in my cmdline. It seems that omap-serial.c console suspends
the hardware while earlyprintk is still trying to access it?

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 12:16                 ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-08 12:16 UTC (permalink / raw)
  To: linux-arm-kernel

* Tony Lindgren <tony@atomide.com> [130708 04:32]:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
> > On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> > > Hi Tony,
> > > 
> > > On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> > > > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> > > > > 
> > > > > I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> > > > > provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> > > > > that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> > > > > also results in the console UART getting reset and idled during bootup and that's where
> > > > > the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> > > > > the system booting fine. 
> > > > > 
> > > > > I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> > > > > omap_serial_early_init() to get earlyprintk working again.
> > > > 
> > > > Hmm nothing should get idled while earlyprintk is running, and then when the
> > > > serial driver kicks in it should not idle anything by default. And for DT based
> > > > booting we should not have mach-omap2/serial.c initialize anything.
> > > > 
> > > 
> > > If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> > > comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> > > just like Mark reported.
> > > 
> > 
> > Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> 
> It sounds like something needs to be fixed for am33xx as omap3 and omap4
> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> be needed at all for am33xx, and the bug is somewhere else.

Oops, sorry correction: I'm seeing it, I did not have console=ttyO
earlier in my cmdline. It seems that omap-serial.c console suspends
the hardware while earlyprintk is still trying to access it?

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 11:25               ` Tony Lindgren
@ 2013-07-08 12:41                 ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-08 12:41 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar

On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>> Hi Tony,
>>>
>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
>>>>>
>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>> the system booting fine. 
>>>>>
>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>
>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>
>>>
>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>> just like Mark reported.
>>>
>>
>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> 
> It sounds like something needs to be fixed for am33xx as omap3 and omap4
> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> be needed at all for am33xx, and the bug is somewhere else.

Tony, I spent some time on this today and there seem to 2 issues.

Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)

The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
"ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
console UART. With this not happening now for the DT case, it causes an issue.

The issue was seen on am33xx and not on some other platforms because some platforms still have these
statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
So I feel the above commit should be reverted and these static flags should be removed from the data
files.

>  
>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>> of -1 for the serial driver?
>>>>
>>>
>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> 
> OK

Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)

I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"

What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0

from serial_omap_runtime_resume():
-----
        int loss_cnt = serial_omap_get_context_loss_count(up);

        if (loss_cnt < 0) {
                dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
                        loss_cnt);
                serial_omap_restore_context(up);
        } else if (up->context_loss_cnt != loss_cnt) {
                serial_omap_restore_context(up);
        }
-----

I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.

Let me know if the fix I listed for Issue 1: makes sense.

regards,
Rajendra

> 
> Regards,
> 
> Tony
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 12:41                 ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-08 12:41 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>> Hi Tony,
>>>
>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
>>>>>
>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>> the system booting fine. 
>>>>>
>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>
>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>
>>>
>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>> just like Mark reported.
>>>
>>
>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> 
> It sounds like something needs to be fixed for am33xx as omap3 and omap4
> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> be needed at all for am33xx, and the bug is somewhere else.

Tony, I spent some time on this today and there seem to 2 issues.

Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)

The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
"ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
console UART. With this not happening now for the DT case, it causes an issue.

The issue was seen on am33xx and not on some other platforms because some platforms still have these
statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
So I feel the above commit should be reverted and these static flags should be removed from the data
files.

>  
>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>> of -1 for the serial driver?
>>>>
>>>
>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> 
> OK

Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)

I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"

What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0

from serial_omap_runtime_resume():
-----
        int loss_cnt = serial_omap_get_context_loss_count(up);

        if (loss_cnt < 0) {
                dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
                        loss_cnt);
                serial_omap_restore_context(up);
        } else if (up->context_loss_cnt != loss_cnt) {
                serial_omap_restore_context(up);
        }
-----

I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.

Let me know if the fix I listed for Issue 1: makes sense.

regards,
Rajendra

> 
> Regards,
> 
> Tony
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 12:41                 ` Rajendra Nayak
@ 2013-07-08 13:10                   ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-08 13:10 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar

* Rajendra Nayak <rnayak@ti.com> [130708 05:48]:
> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
> > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
> >> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> >>> Hi Tony,
> >>>
> >>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> >>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> >>>>>
> >>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> >>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> >>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> >>>>> also results in the console UART getting reset and idled during bootup and that's where
> >>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> >>>>> the system booting fine. 
> >>>>>
> >>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> >>>>> omap_serial_early_init() to get earlyprintk working again.
> >>>>
> >>>> Hmm nothing should get idled while earlyprintk is running, and then when the
> >>>> serial driver kicks in it should not idle anything by default. And for DT based
> >>>> booting we should not have mach-omap2/serial.c initialize anything.
> >>>>
> >>>
> >>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> >>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> >>> just like Mark reported.
> >>>
> >>
> >> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> > 
> > It sounds like something needs to be fixed for am33xx as omap3 and omap4
> > won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> > be needed at all for am33xx, and the bug is somewhere else.
> 
> Tony, I spent some time on this today and there seem to 2 issues.
> 
> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
> 
> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
> console UART. With this not happening now for the DT case, it causes an issue.
> 
> The issue was seen on am33xx and not on some other platforms because some platforms still have these
> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
> So I feel the above commit should be reverted and these static flags should be removed from the data
> files.

Oh OK. That's starting to make a bit more sense then. 
  
> >>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>> of -1 for the serial driver?
> >>>>
> >>>
> >>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> > 
> > OK
> 
> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
> 
> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
> 
> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
> 
> from serial_omap_runtime_resume():
> -----
>         int loss_cnt = serial_omap_get_context_loss_count(up);
> 
>         if (loss_cnt < 0) {
>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>                         loss_cnt);
>                 serial_omap_restore_context(up);
>         } else if (up->context_loss_cnt != loss_cnt) {
>                 serial_omap_restore_context(up);
>         }
> -----
> 
> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.

That's because we don't have the omap specific pdata callbacks for
context loss any longer. We may be able to detect when the context
was really lost in the serial driver, and only then call the
serial_omap_restore_context().
 
> Let me know if the fix I listed for Issue 1: makes sense.

Yes makes sense as a fix, but IMHO we should not need any workarounds
like that. Is the hwmod code idling the the uarts early? If so, then
it should only do that in a late_initcall if no drivers are registered.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 13:10                   ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-08 13:10 UTC (permalink / raw)
  To: linux-arm-kernel

* Rajendra Nayak <rnayak@ti.com> [130708 05:48]:
> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
> > * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
> >> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
> >>> Hi Tony,
> >>>
> >>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
> >>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
> >>>>>
> >>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
> >>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
> >>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
> >>>>> also results in the console UART getting reset and idled during bootup and that's where
> >>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
> >>>>> the system booting fine. 
> >>>>>
> >>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
> >>>>> omap_serial_early_init() to get earlyprintk working again.
> >>>>
> >>>> Hmm nothing should get idled while earlyprintk is running, and then when the
> >>>> serial driver kicks in it should not idle anything by default. And for DT based
> >>>> booting we should not have mach-omap2/serial.c initialize anything.
> >>>>
> >>>
> >>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
> >>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
> >>> just like Mark reported.
> >>>
> >>
> >> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
> > 
> > It sounds like something needs to be fixed for am33xx as omap3 and omap4
> > won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
> > be needed at all for am33xx, and the bug is somewhere else.
> 
> Tony, I spent some time on this today and there seem to 2 issues.
> 
> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
> 
> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
> console UART. With this not happening now for the DT case, it causes an issue.
> 
> The issue was seen on am33xx and not on some other platforms because some platforms still have these
> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
> So I feel the above commit should be reverted and these static flags should be removed from the data
> files.

Oh OK. That's starting to make a bit more sense then. 
  
> >>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>> of -1 for the serial driver?
> >>>>
> >>>
> >>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> > 
> > OK
> 
> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
> 
> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
> 
> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
> 
> from serial_omap_runtime_resume():
> -----
>         int loss_cnt = serial_omap_get_context_loss_count(up);
> 
>         if (loss_cnt < 0) {
>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>                         loss_cnt);
>                 serial_omap_restore_context(up);
>         } else if (up->context_loss_cnt != loss_cnt) {
>                 serial_omap_restore_context(up);
>         }
> -----
> 
> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.

That's because we don't have the omap specific pdata callbacks for
context loss any longer. We may be able to detect when the context
was really lost in the serial driver, and only then call the
serial_omap_restore_context().
 
> Let me know if the fix I listed for Issue 1: makes sense.

Yes makes sense as a fix, but IMHO we should not need any workarounds
like that. Is the hwmod code idling the the uarts early? If so, then
it should only do that in a late_initcall if no drivers are registered.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 13:10                   ` Tony Lindgren
@ 2013-07-08 13:20                     ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-08 13:20 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar, Paul Walmsley

On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@ti.com> [130708 05:48]:
>> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
>>>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>>>> Hi Tony,
>>>>>
>>>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
>>>>>>>
>>>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>>>> the system booting fine. 
>>>>>>>
>>>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>>>
>>>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>>>
>>>>>
>>>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>>>> just like Mark reported.
>>>>>
>>>>
>>>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
>>>
>>> It sounds like something needs to be fixed for am33xx as omap3 and omap4
>>> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
>>> be needed at all for am33xx, and the bug is somewhere else.
>>
>> Tony, I spent some time on this today and there seem to 2 issues.
>>
>> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
>>
>> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
>> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
>> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
>> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
>> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
>> console UART. With this not happening now for the DT case, it causes an issue.
>>
>> The issue was seen on am33xx and not on some other platforms because some platforms still have these
>> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
>> So I feel the above commit should be reverted and these static flags should be removed from the data
>> files.
> 
> Oh OK. That's starting to make a bit more sense then. 
>   
>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>> of -1 for the serial driver?
>>>>>>
>>>>>
>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>
>>> OK
>>
>> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
>>
>> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
>> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
>>
>> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
>> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
>>
>> from serial_omap_runtime_resume():
>> -----
>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>
>>         if (loss_cnt < 0) {
>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>                         loss_cnt);
>>                 serial_omap_restore_context(up);
>>         } else if (up->context_loss_cnt != loss_cnt) {
>>                 serial_omap_restore_context(up);
>>         }
>> -----
>>
>> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
>> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.
> 
> That's because we don't have the omap specific pdata callbacks for
> context loss any longer. We may be able to detect when the context
> was really lost in the serial driver, and only then call the
> serial_omap_restore_context().

Right, but calling serial_omap_restore_context() even when the context is not lost, should not
ideally cause an issue.

>  
>> Let me know if the fix I listed for Issue 1: makes sense.
> 
> Yes makes sense as a fix, but IMHO we should not need any workarounds
> like that. Is the hwmod code idling the the uarts early? If so, then
> it should only do that in a late_initcall if no drivers are registered.

hwmod as part of its setup (early) enables/resets and idles all modules.
These flags are used to tell hwmod to avoid a reset and idle and leave the
module enabled (in this case console uart)

regards
Rajendra

> 
> Regards,
> 
> Tony
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 13:20                     ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-08 13:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@ti.com> [130708 05:48]:
>> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
>>>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>>>> Hi Tony,
>>>>>
>>>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
>>>>>>>
>>>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>>>> the system booting fine. 
>>>>>>>
>>>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>>>
>>>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>>>
>>>>>
>>>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>>>> just like Mark reported.
>>>>>
>>>>
>>>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
>>>
>>> It sounds like something needs to be fixed for am33xx as omap3 and omap4
>>> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
>>> be needed at all for am33xx, and the bug is somewhere else.
>>
>> Tony, I spent some time on this today and there seem to 2 issues.
>>
>> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
>>
>> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
>> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
>> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
>> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
>> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
>> console UART. With this not happening now for the DT case, it causes an issue.
>>
>> The issue was seen on am33xx and not on some other platforms because some platforms still have these
>> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
>> So I feel the above commit should be reverted and these static flags should be removed from the data
>> files.
> 
> Oh OK. That's starting to make a bit more sense then. 
>   
>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>> of -1 for the serial driver?
>>>>>>
>>>>>
>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>
>>> OK
>>
>> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
>>
>> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
>> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
>>
>> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
>> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
>>
>> from serial_omap_runtime_resume():
>> -----
>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>
>>         if (loss_cnt < 0) {
>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>                         loss_cnt);
>>                 serial_omap_restore_context(up);
>>         } else if (up->context_loss_cnt != loss_cnt) {
>>                 serial_omap_restore_context(up);
>>         }
>> -----
>>
>> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
>> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.
> 
> That's because we don't have the omap specific pdata callbacks for
> context loss any longer. We may be able to detect when the context
> was really lost in the serial driver, and only then call the
> serial_omap_restore_context().

Right, but calling serial_omap_restore_context() even when the context is not lost, should not
ideally cause an issue.

>  
>> Let me know if the fix I listed for Issue 1: makes sense.
> 
> Yes makes sense as a fix, but IMHO we should not need any workarounds
> like that. Is the hwmod code idling the the uarts early? If so, then
> it should only do that in a late_initcall if no drivers are registered.

hwmod as part of its setup (early) enables/resets and idles all modules.
These flags are used to tell hwmod to avoid a reset and idle and leave the
module enabled (in this case console uart)

regards
Rajendra

> 
> Regards,
> 
> Tony
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 13:20                     ` Rajendra Nayak
@ 2013-07-08 13:25                       ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-08 13:25 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Paul Walmsley, Mark Jackson, Bedia, Vaibhav, Sourav Poddar,
	linux-omap, linux-arm-kernel

On Monday 08 July 2013 06:50 PM, Rajendra Nayak wrote:
> On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
>> * Rajendra Nayak <rnayak@ti.com> [130708 05:48]:
>>> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
>>>>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>>>>> Hi Tony,
>>>>>>
>>>>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
>>>>>>>>
>>>>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>>>>> the system booting fine. 
>>>>>>>>
>>>>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>>>>
>>>>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>>>>
>>>>>>
>>>>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>>>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>>>>> just like Mark reported.
>>>>>>
>>>>>
>>>>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
>>>>
>>>> It sounds like something needs to be fixed for am33xx as omap3 and omap4
>>>> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
>>>> be needed at all for am33xx, and the bug is somewhere else.
>>>
>>> Tony, I spent some time on this today and there seem to 2 issues.
>>>
>>> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
>>>
>>> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
>>> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
>>> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
>>> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
>>> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
>>> console UART. With this not happening now for the DT case, it causes an issue.
>>>
>>> The issue was seen on am33xx and not on some other platforms because some platforms still have these
>>> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
>>> So I feel the above commit should be reverted and these static flags should be removed from the data
>>> files.
>>
>> Oh OK. That's starting to make a bit more sense then. 
>>   
>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>> of -1 for the serial driver?
>>>>>>>
>>>>>>
>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>
>>>> OK
>>>
>>> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
>>>
>>> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
>>> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
>>>
>>> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
>>> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
>>>
>>> from serial_omap_runtime_resume():
>>> -----
>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>
>>>         if (loss_cnt < 0) {
>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>                         loss_cnt);
>>>                 serial_omap_restore_context(up);
>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>                 serial_omap_restore_context(up);
>>>         }
>>> -----
>>>
>>> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
>>> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.
>>
>> That's because we don't have the omap specific pdata callbacks for
>> context loss any longer. We may be able to detect when the context
>> was really lost in the serial driver, and only then call the
>> serial_omap_restore_context().
> 
> Right, but calling serial_omap_restore_context() even when the context is not lost, should not
> ideally cause an issue.

So looking some more into this, it turns out a lot of what serial_omap_restore_context() restores
gets set as part of serial_omap_set_termios() which infact gets called much later and any call to
serial_omap_restore_context before a call to serial_omap_set_termios() ends up restoring junk?

> 
>>  
>>> Let me know if the fix I listed for Issue 1: makes sense.
>>
>> Yes makes sense as a fix, but IMHO we should not need any workarounds
>> like that. Is the hwmod code idling the the uarts early? If so, then
>> it should only do that in a late_initcall if no drivers are registered.
> 
> hwmod as part of its setup (early) enables/resets and idles all modules.
> These flags are used to tell hwmod to avoid a reset and idle and leave the
> module enabled (in this case console uart)
> 
> regards
> Rajendra
> 
>>
>> Regards,
>>
>> Tony
>>
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 13:25                       ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-08 13:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 08 July 2013 06:50 PM, Rajendra Nayak wrote:
> On Monday 08 July 2013 06:40 PM, Tony Lindgren wrote:
>> * Rajendra Nayak <rnayak@ti.com> [130708 05:48]:
>>> On Monday 08 July 2013 04:55 PM, Tony Lindgren wrote:
>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 06:37]:
>>>>> On Fri, Jul 05, 2013 at 18:50:10, Bedia, Vaibhav wrote:
>>>>>> Hi Tony,
>>>>>>
>>>>>> On Fri, Jul 05, 2013 at 17:29:59, Tony Lindgren wrote:
>>>>>>> * Bedia, Vaibhav <vaibhav.bedia@ti.com> [130705 01:17]:
>>>>>>>>
>>>>>>>> I just checked the behavior on my AM335x-EVM. Current mainline boots fine
>>>>>>>> provided I don't use earlyprintk.  The offending patch [1] in this case is the one
>>>>>>>> that tries to get rid of omap_serial_early_init() for DT boot. This change inadvertently
>>>>>>>> also results in the console UART getting reset and idled during bootup and that's where
>>>>>>>> the boot stops for you. I think if you skip earlyprintk from the bootargs you should see
>>>>>>>> the system booting fine. 
>>>>>>>>
>>>>>>>> I guess we need to retain the NO_IDLE and NO_RESET aspect for the console UART in
>>>>>>>> omap_serial_early_init() to get earlyprintk working again.
>>>>>>>
>>>>>>> Hmm nothing should get idled while earlyprintk is running, and then when the
>>>>>>> serial driver kicks in it should not idle anything by default. And for DT based
>>>>>>> booting we should not have mach-omap2/serial.c initialize anything.
>>>>>>>
>>>>>>
>>>>>> If I add in the HWMOD flags without any reverts I get to the point where the serial driver
>>>>>> comes up but the boot eventually stops [1]. Without the flags the boot stops much earlier [2]
>>>>>> just like Mark reported.
>>>>>>
>>>>>
>>>>> Err.. the log with HWMOD flags added is [2] and without flags is [1]. Sorry for the confusion.
>>>>
>>>> It sounds like something needs to be fixed for am33xx as omap3 and omap4
>>>> won't hang with earlyprintk. Almost certainly mach-omap2/serial.c should not
>>>> be needed at all for am33xx, and the bug is somewhere else.
>>>
>>> Tony, I spent some time on this today and there seem to 2 issues.
>>>
>>> Issue 1: Causing boot to stop much earlier as reported (this is during hmwod setup)
>>>
>>> The commit 'e97f03cb36e9ec8a2ccaa3e4bee5297fe48156fd' 
>>> "ARM: OMAP2+: Fix serial init for device tree based booting" stubbed out omap_serial_early_init()
>>> for DT case thinking its doing the port inits. But that does not seem to be true, the port inits happen
>>> as part of omap_serial_init_port(). What omap_serial_early_init() was doing instead was adding the
>>> HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags which would tell hmwod not to reset and then idle the
>>> console UART. With this not happening now for the DT case, it causes an issue.
>>>
>>> The issue was seen on am33xx and not on some other platforms because some platforms still have these
>>> statically defined in the hwmod data files. I could see these set for uart3 in case of omap4 and omap5.
>>> So I feel the above commit should be reverted and these static flags should be removed from the data
>>> files.
>>
>> Oh OK. That's starting to make a bit more sense then. 
>>   
>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>> of -1 for the serial driver?
>>>>>>>
>>>>>>
>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>
>>>> OK
>>>
>>> Issue 2: Causing boot to stop when serial driver is initialized. (After Issue 1 is fixed)
>>>
>>> I could narrow this down to the change done to return -EINVAL instead of 0 in serial_omap_get_context_loss_count()
>>> as part of commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap: Fix device tree based PM runtime"
>>>
>>> What this change in turn seems to do is cause a serial_omap_restore_context() to get called as part of
>>> serial_omap_runtime_resume() which was not the case when serial_omap_get_context_loss_count() returned 0
>>>
>>> from serial_omap_runtime_resume():
>>> -----
>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>
>>>         if (loss_cnt < 0) {
>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>                         loss_cnt);
>>>                 serial_omap_restore_context(up);
>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>                 serial_omap_restore_context(up);
>>>         }
>>> -----
>>>
>>> I am still working on why a serial_omap_restore_context() could have caused console to die. I will work with
>>> Sourav on this and post the fixes for both issue 1 and issue2 once its clear on whats really causing issue 2.
>>
>> That's because we don't have the omap specific pdata callbacks for
>> context loss any longer. We may be able to detect when the context
>> was really lost in the serial driver, and only then call the
>> serial_omap_restore_context().
> 
> Right, but calling serial_omap_restore_context() even when the context is not lost, should not
> ideally cause an issue.

So looking some more into this, it turns out a lot of what serial_omap_restore_context() restores
gets set as part of serial_omap_set_termios() which infact gets called much later and any call to
serial_omap_restore_context before a call to serial_omap_set_termios() ends up restoring junk?

> 
>>  
>>> Let me know if the fix I listed for Issue 1: makes sense.
>>
>> Yes makes sense as a fix, but IMHO we should not need any workarounds
>> like that. Is the hwmod code idling the the uarts early? If so, then
>> it should only do that in a late_initcall if no drivers are registered.
> 
> hwmod as part of its setup (early) enables/resets and idles all modules.
> These flags are used to tell hwmod to avoid a reset and idle and leave the
> module enabled (in this case console uart)
> 
> regards
> Rajendra
> 
>>
>> Regards,
>>
>> Tony
>>
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 13:20                     ` Rajendra Nayak
@ 2013-07-08 13:35                       ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-08 13:35 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Tony Lindgren, Bedia, Vaibhav, linux-omap, linux-arm-kernel,
	Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 4124 bytes --]

Hi,

On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>>>> of -1 for the serial driver?
> >>>>>>
> >>>>>
> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >>>
> >>> OK
> >>
> >> Issue 2: Causing boot to stop when serial driver is initialized.
> >> (After Issue 1 is fixed)
> >>
> >> I could narrow this down to the change done to return -EINVAL
> >> instead of 0 in serial_omap_get_context_loss_count() as part of
> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >> Fix device tree based PM runtime"
> >>
> >> What this change in turn seems to do is cause a
> >> serial_omap_restore_context() to get called as part of
> >> serial_omap_runtime_resume() which was not the case when
> >> serial_omap_get_context_loss_count() returned 0
> >>
> >> from serial_omap_runtime_resume():
> >> -----
> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >>
> >>         if (loss_cnt < 0) {
> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >>                         loss_cnt);
> >>                 serial_omap_restore_context(up);
> >>         } else if (up->context_loss_cnt != loss_cnt) {
> >>                 serial_omap_restore_context(up);
> >>         }
> >> -----
> >>
> >> I am still working on why a serial_omap_restore_context() could
> >> have caused console to die. I will work with Sourav on this and
> >> post the fixes for both issue 1 and issue2 once its clear on whats
> >> really causing issue 2.
> > 
> > That's because we don't have the omap specific pdata callbacks for
> > context loss any longer. We may be able to detect when the context
> > was really lost in the serial driver, and only then call the
> > serial_omap_restore_context().
> 
> Right, but calling serial_omap_restore_context() even when the context
> is not lost, should not ideally cause an issue.

it does in one condition. If context hasn't been saved before. And that
can happen in the case of wrong pm runtime status for that device.

Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then when you call pm_runtime_get_sync() on probe() your
->runtime_resume() will get called, which will restore context,
essentially undoing anything which was configured by u-boot.

Am I missing something ?

> >> Let me know if the fix I listed for Issue 1: makes sense.
> > 
> > Yes makes sense as a fix, but IMHO we should not need any workarounds
> > like that. Is the hwmod code idling the the uarts early? If so, then
> > it should only do that in a late_initcall if no drivers are registered.
> 
> hwmod as part of its setup (early) enables/resets and idles all modules.
> These flags are used to tell hwmod to avoid a reset and idle and leave the
> module enabled (in this case console uart)

then it needs to call pm_runtime_set_active() for those devices which
have that flag set, right ?

(completely untested, didn't even try to compile, just to illustrate)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..d8dca68 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
 	    (postsetup_state == _HWMOD_STATE_IDLE)) {
 		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
 		postsetup_state = _HWMOD_STATE_ENABLED;
+
+		/* tell pm_runtime this device is already active */
+		pm_runtime_set_active(&oh->od->pdev->dev);
+	} else {
+		/* tell pm_runtime this device is trully suspended */
+		pm_runtime_set_suspended(&oh->od->pdev->dev);
 	}
 
 	if (postsetup_state == _HWMOD_STATE_IDLE)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-08 13:35                       ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-08 13:35 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>>>> of -1 for the serial driver?
> >>>>>>
> >>>>>
> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >>>
> >>> OK
> >>
> >> Issue 2: Causing boot to stop when serial driver is initialized.
> >> (After Issue 1 is fixed)
> >>
> >> I could narrow this down to the change done to return -EINVAL
> >> instead of 0 in serial_omap_get_context_loss_count() as part of
> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >> Fix device tree based PM runtime"
> >>
> >> What this change in turn seems to do is cause a
> >> serial_omap_restore_context() to get called as part of
> >> serial_omap_runtime_resume() which was not the case when
> >> serial_omap_get_context_loss_count() returned 0
> >>
> >> from serial_omap_runtime_resume():
> >> -----
> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >>
> >>         if (loss_cnt < 0) {
> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >>                         loss_cnt);
> >>                 serial_omap_restore_context(up);
> >>         } else if (up->context_loss_cnt != loss_cnt) {
> >>                 serial_omap_restore_context(up);
> >>         }
> >> -----
> >>
> >> I am still working on why a serial_omap_restore_context() could
> >> have caused console to die. I will work with Sourav on this and
> >> post the fixes for both issue 1 and issue2 once its clear on whats
> >> really causing issue 2.
> > 
> > That's because we don't have the omap specific pdata callbacks for
> > context loss any longer. We may be able to detect when the context
> > was really lost in the serial driver, and only then call the
> > serial_omap_restore_context().
> 
> Right, but calling serial_omap_restore_context() even when the context
> is not lost, should not ideally cause an issue.

it does in one condition. If context hasn't been saved before. And that
can happen in the case of wrong pm runtime status for that device.

Imagine the device is marked as suspended even though it's fully enabled
(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
your context structure is all zeroes (context has never been saved
before) then when you call pm_runtime_get_sync() on probe() your
->runtime_resume() will get called, which will restore context,
essentially undoing anything which was configured by u-boot.

Am I missing something ?

> >> Let me know if the fix I listed for Issue 1: makes sense.
> > 
> > Yes makes sense as a fix, but IMHO we should not need any workarounds
> > like that. Is the hwmod code idling the the uarts early? If so, then
> > it should only do that in a late_initcall if no drivers are registered.
> 
> hwmod as part of its setup (early) enables/resets and idles all modules.
> These flags are used to tell hwmod to avoid a reset and idle and leave the
> module enabled (in this case console uart)

then it needs to call pm_runtime_set_active() for those devices which
have that flag set, right ?

(completely untested, didn't even try to compile, just to illustrate)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..d8dca68 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
 	    (postsetup_state == _HWMOD_STATE_IDLE)) {
 		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
 		postsetup_state = _HWMOD_STATE_ENABLED;
+
+		/* tell pm_runtime this device is already active */
+		pm_runtime_set_active(&oh->od->pdev->dev);
+	} else {
+		/* tell pm_runtime this device is trully suspended */
+		pm_runtime_set_suspended(&oh->od->pdev->dev);
 	}
 
 	if (postsetup_state == _HWMOD_STATE_IDLE)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130708/37396e9a/attachment-0001.sig>

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 13:35                       ` Felipe Balbi
@ 2013-07-09  5:33                         ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-09  5:33 UTC (permalink / raw)
  To: balbi
  Cc: Tony Lindgren, Bedia, Vaibhav, linux-omap, linux-arm-kernel,
	Mark Jackson, Sourav Poddar, Paul Walmsley

On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>> of -1 for the serial driver?
>>>>>>>>
>>>>>>>
>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>
>>>>> OK
>>>>
>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>> (After Issue 1 is fixed)
>>>>
>>>> I could narrow this down to the change done to return -EINVAL
>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>> Fix device tree based PM runtime"
>>>>
>>>> What this change in turn seems to do is cause a
>>>> serial_omap_restore_context() to get called as part of
>>>> serial_omap_runtime_resume() which was not the case when
>>>> serial_omap_get_context_loss_count() returned 0
>>>>
>>>> from serial_omap_runtime_resume():
>>>> -----
>>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>
>>>>         if (loss_cnt < 0) {
>>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>                         loss_cnt);
>>>>                 serial_omap_restore_context(up);
>>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>>                 serial_omap_restore_context(up);
>>>>         }
>>>> -----
>>>>
>>>> I am still working on why a serial_omap_restore_context() could
>>>> have caused console to die. I will work with Sourav on this and
>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>> really causing issue 2.
>>>
>>> That's because we don't have the omap specific pdata callbacks for
>>> context loss any longer. We may be able to detect when the context
>>> was really lost in the serial driver, and only then call the
>>> serial_omap_restore_context().
>>
>> Right, but calling serial_omap_restore_context() even when the context
>> is not lost, should not ideally cause an issue.
> 
> it does in one condition. If context hasn't been saved before. And that
> can happen in the case of wrong pm runtime status for that device.
> 
> Imagine the device is marked as suspended even though it's fully enabled
> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> your context structure is all zeroes (context has never been saved
> before) then when you call pm_runtime_get_sync() on probe() your
> ->runtime_resume() will get called, which will restore context,
> essentially undoing anything which was configured by u-boot.

This could be a problem for drivers which do a save context in ->runtime_suspend()
but from what I see with omap serial, there is no save context done as part of
->runtime_suspend.

> 
> Am I missing something ?
> 
>>>> Let me know if the fix I listed for Issue 1: makes sense.
>>>
>>> Yes makes sense as a fix, but IMHO we should not need any workarounds
>>> like that. Is the hwmod code idling the the uarts early? If so, then
>>> it should only do that in a late_initcall if no drivers are registered.
>>
>> hwmod as part of its setup (early) enables/resets and idles all modules.
>> These flags are used to tell hwmod to avoid a reset and idle and leave the
>> module enabled (in this case console uart)
> 
> then it needs to call pm_runtime_set_active() for those devices which
> have that flag set, right ?
> 
> (completely untested, didn't even try to compile, just to illustrate)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 7341eff..d8dca68 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>  		postsetup_state = _HWMOD_STATE_ENABLED;
> +
> +		/* tell pm_runtime this device is already active */
> +		pm_runtime_set_active(&oh->od->pdev->dev);
> +	} else {
> +		/* tell pm_runtime this device is trully suspended */
> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>  	}
>  
>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-09  5:33                         ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-09  5:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>> of -1 for the serial driver?
>>>>>>>>
>>>>>>>
>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>
>>>>> OK
>>>>
>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>> (After Issue 1 is fixed)
>>>>
>>>> I could narrow this down to the change done to return -EINVAL
>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>> Fix device tree based PM runtime"
>>>>
>>>> What this change in turn seems to do is cause a
>>>> serial_omap_restore_context() to get called as part of
>>>> serial_omap_runtime_resume() which was not the case when
>>>> serial_omap_get_context_loss_count() returned 0
>>>>
>>>> from serial_omap_runtime_resume():
>>>> -----
>>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>
>>>>         if (loss_cnt < 0) {
>>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>                         loss_cnt);
>>>>                 serial_omap_restore_context(up);
>>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>>                 serial_omap_restore_context(up);
>>>>         }
>>>> -----
>>>>
>>>> I am still working on why a serial_omap_restore_context() could
>>>> have caused console to die. I will work with Sourav on this and
>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>> really causing issue 2.
>>>
>>> That's because we don't have the omap specific pdata callbacks for
>>> context loss any longer. We may be able to detect when the context
>>> was really lost in the serial driver, and only then call the
>>> serial_omap_restore_context().
>>
>> Right, but calling serial_omap_restore_context() even when the context
>> is not lost, should not ideally cause an issue.
> 
> it does in one condition. If context hasn't been saved before. And that
> can happen in the case of wrong pm runtime status for that device.
> 
> Imagine the device is marked as suspended even though it's fully enabled
> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> your context structure is all zeroes (context has never been saved
> before) then when you call pm_runtime_get_sync() on probe() your
> ->runtime_resume() will get called, which will restore context,
> essentially undoing anything which was configured by u-boot.

This could be a problem for drivers which do a save context in ->runtime_suspend()
but from what I see with omap serial, there is no save context done as part of
->runtime_suspend.

> 
> Am I missing something ?
> 
>>>> Let me know if the fix I listed for Issue 1: makes sense.
>>>
>>> Yes makes sense as a fix, but IMHO we should not need any workarounds
>>> like that. Is the hwmod code idling the the uarts early? If so, then
>>> it should only do that in a late_initcall if no drivers are registered.
>>
>> hwmod as part of its setup (early) enables/resets and idles all modules.
>> These flags are used to tell hwmod to avoid a reset and idle and leave the
>> module enabled (in this case console uart)
> 
> then it needs to call pm_runtime_set_active() for those devices which
> have that flag set, right ?
> 
> (completely untested, didn't even try to compile, just to illustrate)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 7341eff..d8dca68 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>  		postsetup_state = _HWMOD_STATE_ENABLED;
> +
> +		/* tell pm_runtime this device is already active */
> +		pm_runtime_set_active(&oh->od->pdev->dev);
> +	} else {
> +		/* tell pm_runtime this device is trully suspended */
> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>  	}
>  
>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-09  5:33                         ` Rajendra Nayak
@ 2013-07-09  6:42                           ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-09  6:42 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: balbi, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]

Hi,

On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>>>>>> of -1 for the serial driver?
> >>>>>>>>
> >>>>>>>
> >>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >>>>>
> >>>>> OK
> >>>>
> >>>> Issue 2: Causing boot to stop when serial driver is initialized.
> >>>> (After Issue 1 is fixed)
> >>>>
> >>>> I could narrow this down to the change done to return -EINVAL
> >>>> instead of 0 in serial_omap_get_context_loss_count() as part of
> >>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >>>> Fix device tree based PM runtime"
> >>>>
> >>>> What this change in turn seems to do is cause a
> >>>> serial_omap_restore_context() to get called as part of
> >>>> serial_omap_runtime_resume() which was not the case when
> >>>> serial_omap_get_context_loss_count() returned 0
> >>>>
> >>>> from serial_omap_runtime_resume():
> >>>> -----
> >>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >>>>
> >>>>         if (loss_cnt < 0) {
> >>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >>>>                         loss_cnt);
> >>>>                 serial_omap_restore_context(up);
> >>>>         } else if (up->context_loss_cnt != loss_cnt) {
> >>>>                 serial_omap_restore_context(up);
> >>>>         }
> >>>> -----
> >>>>
> >>>> I am still working on why a serial_omap_restore_context() could
> >>>> have caused console to die. I will work with Sourav on this and
> >>>> post the fixes for both issue 1 and issue2 once its clear on whats
> >>>> really causing issue 2.
> >>>
> >>> That's because we don't have the omap specific pdata callbacks for
> >>> context loss any longer. We may be able to detect when the context
> >>> was really lost in the serial driver, and only then call the
> >>> serial_omap_restore_context().
> >>
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> > 
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> > 
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> 
> This could be a problem for drivers which do a save context in ->runtime_suspend()
> but from what I see with omap serial, there is no save context done as part of
> ->runtime_suspend.

right, because context is "saved" in set_termios. probe() will get
called much before set_termios() has a chance to run, right ?

Same problem will trigger in that case.

I still think patch below is necessary

> > (completely untested, didn't even try to compile, just to illustrate)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> > index 7341eff..d8dca68 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >  		postsetup_state = _HWMOD_STATE_ENABLED;
> > +
> > +		/* tell pm_runtime this device is already active */
> > +		pm_runtime_set_active(&oh->od->pdev->dev);
> > +	} else {
> > +		/* tell pm_runtime this device is trully suspended */
> > +		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >  	}
> >  
> >  	if (postsetup_state == _HWMOD_STATE_IDLE)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-09  6:42                           ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-09  6:42 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >>>>>>>> of -1 for the serial driver?
> >>>>>>>>
> >>>>>>>
> >>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >>>>>
> >>>>> OK
> >>>>
> >>>> Issue 2: Causing boot to stop when serial driver is initialized.
> >>>> (After Issue 1 is fixed)
> >>>>
> >>>> I could narrow this down to the change done to return -EINVAL
> >>>> instead of 0 in serial_omap_get_context_loss_count() as part of
> >>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >>>> Fix device tree based PM runtime"
> >>>>
> >>>> What this change in turn seems to do is cause a
> >>>> serial_omap_restore_context() to get called as part of
> >>>> serial_omap_runtime_resume() which was not the case when
> >>>> serial_omap_get_context_loss_count() returned 0
> >>>>
> >>>> from serial_omap_runtime_resume():
> >>>> -----
> >>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >>>>
> >>>>         if (loss_cnt < 0) {
> >>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >>>>                         loss_cnt);
> >>>>                 serial_omap_restore_context(up);
> >>>>         } else if (up->context_loss_cnt != loss_cnt) {
> >>>>                 serial_omap_restore_context(up);
> >>>>         }
> >>>> -----
> >>>>
> >>>> I am still working on why a serial_omap_restore_context() could
> >>>> have caused console to die. I will work with Sourav on this and
> >>>> post the fixes for both issue 1 and issue2 once its clear on whats
> >>>> really causing issue 2.
> >>>
> >>> That's because we don't have the omap specific pdata callbacks for
> >>> context loss any longer. We may be able to detect when the context
> >>> was really lost in the serial driver, and only then call the
> >>> serial_omap_restore_context().
> >>
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> > 
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> > 
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> 
> This could be a problem for drivers which do a save context in ->runtime_suspend()
> but from what I see with omap serial, there is no save context done as part of
> ->runtime_suspend.

right, because context is "saved" in set_termios. probe() will get
called much before set_termios() has a chance to run, right ?

Same problem will trigger in that case.

I still think patch below is necessary

> > (completely untested, didn't even try to compile, just to illustrate)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> > index 7341eff..d8dca68 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >  		postsetup_state = _HWMOD_STATE_ENABLED;
> > +
> > +		/* tell pm_runtime this device is already active */
> > +		pm_runtime_set_active(&oh->od->pdev->dev);
> > +	} else {
> > +		/* tell pm_runtime this device is trully suspended */
> > +		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >  	}
> >  
> >  	if (postsetup_state == _HWMOD_STATE_IDLE)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130709/1fb8a557/attachment.sig>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-09  6:42                           ` Felipe Balbi
@ 2013-07-09  7:19                             ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-09  7:19 UTC (permalink / raw)
  To: balbi
  Cc: Tony Lindgren, Bedia, Vaibhav, linux-omap, linux-arm-kernel,
	Mark Jackson, Sourav Poddar, Paul Walmsley

On Tuesday 09 July 2013 12:12 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>>>> of -1 for the serial driver?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>>>
>>>>>>> OK
>>>>>>
>>>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>>>> (After Issue 1 is fixed)
>>>>>>
>>>>>> I could narrow this down to the change done to return -EINVAL
>>>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>>>> Fix device tree based PM runtime"
>>>>>>
>>>>>> What this change in turn seems to do is cause a
>>>>>> serial_omap_restore_context() to get called as part of
>>>>>> serial_omap_runtime_resume() which was not the case when
>>>>>> serial_omap_get_context_loss_count() returned 0
>>>>>>
>>>>>> from serial_omap_runtime_resume():
>>>>>> -----
>>>>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>>>
>>>>>>         if (loss_cnt < 0) {
>>>>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>>>                         loss_cnt);
>>>>>>                 serial_omap_restore_context(up);
>>>>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>>>>                 serial_omap_restore_context(up);
>>>>>>         }
>>>>>> -----
>>>>>>
>>>>>> I am still working on why a serial_omap_restore_context() could
>>>>>> have caused console to die. I will work with Sourav on this and
>>>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>>>> really causing issue 2.
>>>>>
>>>>> That's because we don't have the omap specific pdata callbacks for
>>>>> context loss any longer. We may be able to detect when the context
>>>>> was really lost in the serial driver, and only then call the
>>>>> serial_omap_restore_context().
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part of
>> ->runtime_suspend.
> 
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
> 
> Same problem will trigger in that case.
> 
> I still think patch below is necessary

Right, I'll try some on those lines. Looks like a pm_runtime_set_active() is done
for the console in the non DT case in omap_serial_init_port(). It seems to be
missing in the DT case.

Although I feel this should fix the issue we have right now, I wonder if there could
ever be a case with uart being suspended and having to resume again before a
set_termios? What I mean to ask is, if the omap serial driver assuming a resume to
happen only post a set_termios is always valid.

> 
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>  		postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> +		/* tell pm_runtime this device is already active */
>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>> +	} else {
>>> +		/* tell pm_runtime this device is trully suspended */
>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>  	}
>>>  
>>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-09  7:19                             ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-09  7:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday 09 July 2013 12:12 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>>>> of -1 for the serial driver?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>>>
>>>>>>> OK
>>>>>>
>>>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>>>> (After Issue 1 is fixed)
>>>>>>
>>>>>> I could narrow this down to the change done to return -EINVAL
>>>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>>>> Fix device tree based PM runtime"
>>>>>>
>>>>>> What this change in turn seems to do is cause a
>>>>>> serial_omap_restore_context() to get called as part of
>>>>>> serial_omap_runtime_resume() which was not the case when
>>>>>> serial_omap_get_context_loss_count() returned 0
>>>>>>
>>>>>> from serial_omap_runtime_resume():
>>>>>> -----
>>>>>>         int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>>>
>>>>>>         if (loss_cnt < 0) {
>>>>>>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>>>                         loss_cnt);
>>>>>>                 serial_omap_restore_context(up);
>>>>>>         } else if (up->context_loss_cnt != loss_cnt) {
>>>>>>                 serial_omap_restore_context(up);
>>>>>>         }
>>>>>> -----
>>>>>>
>>>>>> I am still working on why a serial_omap_restore_context() could
>>>>>> have caused console to die. I will work with Sourav on this and
>>>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>>>> really causing issue 2.
>>>>>
>>>>> That's because we don't have the omap specific pdata callbacks for
>>>>> context loss any longer. We may be able to detect when the context
>>>>> was really lost in the serial driver, and only then call the
>>>>> serial_omap_restore_context().
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part of
>> ->runtime_suspend.
> 
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
> 
> Same problem will trigger in that case.
> 
> I still think patch below is necessary

Right, I'll try some on those lines. Looks like a pm_runtime_set_active() is done
for the console in the non DT case in omap_serial_init_port(). It seems to be
missing in the DT case.

Although I feel this should fix the issue we have right now, I wonder if there could
ever be a case with uart being suspended and having to resume again before a
set_termios? What I mean to ask is, if the omap serial driver assuming a resume to
happen only post a set_termios is always valid.

> 
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>  		postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> +		/* tell pm_runtime this device is already active */
>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>> +	} else {
>>> +		/* tell pm_runtime this device is trully suspended */
>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>  	}
>>>  
>>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-09  7:19                             ` Rajendra Nayak
@ 2013-07-09  7:40                               ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-09  7:40 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: balbi, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

Hi,

On Tue, Jul 09, 2013 at 12:49:10PM +0530, Rajendra Nayak wrote:
> >>>> Right, but calling serial_omap_restore_context() even when the context
> >>>> is not lost, should not ideally cause an issue.
> >>>
> >>> it does in one condition. If context hasn't been saved before. And that
> >>> can happen in the case of wrong pm runtime status for that device.
> >>>
> >>> Imagine the device is marked as suspended even though it's fully enabled
> >>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>> your context structure is all zeroes (context has never been saved
> >>> before) then when you call pm_runtime_get_sync() on probe() your
> >>> ->runtime_resume() will get called, which will restore context,
> >>> essentially undoing anything which was configured by u-boot.
> >>
> >> This could be a problem for drivers which do a save context in ->runtime_suspend()
> >> but from what I see with omap serial, there is no save context done as part of
> >> ->runtime_suspend.
> > 
> > right, because context is "saved" in set_termios. probe() will get
> > called much before set_termios() has a chance to run, right ?
> > 
> > Same problem will trigger in that case.
> > 
> > I still think patch below is necessary
> 
> Right, I'll try some on those lines. Looks like a
> pm_runtime_set_active() is done for the console in the non DT case in
> omap_serial_init_port(). It seems to be missing in the DT case.

yeah, based on conversation I had with Alan Stern a while back,
pm_runtime_set_*() is best called by the underlying 'bus' and I tend to
agree with him on that.

Our HWMOD being our 'bus' (not really, but still), is the entity which
knows if the device is powered or not and should make sure to call
pm_runtime_set_*() for all devices.

> Although I feel this should fix the issue we have right now, I wonder
> if there could ever be a case with uart being suspended and having to
> resume again before a set_termios? What I mean to ask is, if the omap
> serial driver assuming a resume to happen only post a set_termios is
> always valid.

Meaning, probe() -> suspend() -> resume() ? I don't think that would
ever happen. ->set_termios() would always get called and that's actually
what triggers the resume.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-09  7:40                               ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-09  7:40 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Jul 09, 2013 at 12:49:10PM +0530, Rajendra Nayak wrote:
> >>>> Right, but calling serial_omap_restore_context() even when the context
> >>>> is not lost, should not ideally cause an issue.
> >>>
> >>> it does in one condition. If context hasn't been saved before. And that
> >>> can happen in the case of wrong pm runtime status for that device.
> >>>
> >>> Imagine the device is marked as suspended even though it's fully enabled
> >>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>> your context structure is all zeroes (context has never been saved
> >>> before) then when you call pm_runtime_get_sync() on probe() your
> >>> ->runtime_resume() will get called, which will restore context,
> >>> essentially undoing anything which was configured by u-boot.
> >>
> >> This could be a problem for drivers which do a save context in ->runtime_suspend()
> >> but from what I see with omap serial, there is no save context done as part of
> >> ->runtime_suspend.
> > 
> > right, because context is "saved" in set_termios. probe() will get
> > called much before set_termios() has a chance to run, right ?
> > 
> > Same problem will trigger in that case.
> > 
> > I still think patch below is necessary
> 
> Right, I'll try some on those lines. Looks like a
> pm_runtime_set_active() is done for the console in the non DT case in
> omap_serial_init_port(). It seems to be missing in the DT case.

yeah, based on conversation I had with Alan Stern a while back,
pm_runtime_set_*() is best called by the underlying 'bus' and I tend to
agree with him on that.

Our HWMOD being our 'bus' (not really, but still), is the entity which
knows if the device is powered or not and should make sure to call
pm_runtime_set_*() for all devices.

> Although I feel this should fix the issue we have right now, I wonder
> if there could ever be a case with uart being suspended and having to
> resume again before a set_termios? What I mean to ask is, if the omap
> serial driver assuming a resume to happen only post a set_termios is
> always valid.

Meaning, probe() -> suspend() -> resume() ? I don't think that would
ever happen. ->set_termios() would always get called and that's actually
what triggers the resume.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130709/b1c30c1f/attachment.sig>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-09  6:42                           ` Felipe Balbi
@ 2013-07-09 18:59                             ` Grygorii Strashko
  -1 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-09 18:59 UTC (permalink / raw)
  To: balbi
  Cc: Rajendra Nayak, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

Hi,

On 07/09/2013 09:42 AM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>>>> of -1 for the serial driver?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>>>
>>>>>>> OK
>>>>>>
>>>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>>>> (After Issue 1 is fixed)
>>>>>>
>>>>>> I could narrow this down to the change done to return -EINVAL
>>>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>>>> Fix device tree based PM runtime"
>>>>>>
>>>>>> What this change in turn seems to do is cause a
>>>>>> serial_omap_restore_context() to get called as part of
>>>>>> serial_omap_runtime_resume() which was not the case when
>>>>>> serial_omap_get_context_loss_count() returned 0
>>>>>>
>>>>>> from serial_omap_runtime_resume():
>>>>>> -----
>>>>>>          int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>>>
>>>>>>          if (loss_cnt < 0) {
>>>>>>                  dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>>>                          loss_cnt);
>>>>>>                  serial_omap_restore_context(up);
>>>>>>          } else if (up->context_loss_cnt != loss_cnt) {
>>>>>>                  serial_omap_restore_context(up);
>>>>>>          }
>>>>>> -----
>>>>>>
>>>>>> I am still working on why a serial_omap_restore_context() could
>>>>>> have caused console to die. I will work with Sourav on this and
>>>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>>>> really causing issue 2.
>>>>>
>>>>> That's because we don't have the omap specific pdata callbacks for
>>>>> context loss any longer. We may be able to detect when the context
>>>>> was really lost in the serial driver, and only then call the
>>>>> serial_omap_restore_context().
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part of
>> ->runtime_suspend.
>
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
>
> Same problem will trigger in that case.
>
> I still think patch below is necessary
>
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>   	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>   		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>   		postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> +		/* tell pm_runtime this device is already active */
>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>> +	} else {
>>> +		/* tell pm_runtime this device is trully suspended */
>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>   	}
>>>
>>>   	if (postsetup_state == _HWMOD_STATE_IDLE)
>

This will not work - _setup_postsetup() is called from core_initcall 
level and OMAP devices have not been created at this moment yet 
(of_platform_populate() is called from
customize_machine->init_machine->omap_generic_init() at arch_initcall time)

More over, I don't recommend to depend on hwmod->od field - it's been 
created to support OPPs and it's obsolete now in case of DT use.

Seems, This issue need to be handled in driver for DT boot use case, 
possibly cmdline need to be parsed in the same way as it's done in
omap_serial_early_init().

Regards,
-grygorii


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-09 18:59                             ` Grygorii Strashko
  0 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-09 18:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On 07/09/2013 09:42 AM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 11:03:54AM +0530, Rajendra Nayak wrote:
>> On Monday 08 July 2013 07:05 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>>>>>>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>>>>>>>>>> of -1 for the serial driver?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>>>>>>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>>>>>>>
>>>>>>> OK
>>>>>>
>>>>>> Issue 2: Causing boot to stop when serial driver is initialized.
>>>>>> (After Issue 1 is fixed)
>>>>>>
>>>>>> I could narrow this down to the change done to return -EINVAL
>>>>>> instead of 0 in serial_omap_get_context_loss_count() as part of
>>>>>> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>>>>>> Fix device tree based PM runtime"
>>>>>>
>>>>>> What this change in turn seems to do is cause a
>>>>>> serial_omap_restore_context() to get called as part of
>>>>>> serial_omap_runtime_resume() which was not the case when
>>>>>> serial_omap_get_context_loss_count() returned 0
>>>>>>
>>>>>> from serial_omap_runtime_resume():
>>>>>> -----
>>>>>>          int loss_cnt = serial_omap_get_context_loss_count(up);
>>>>>>
>>>>>>          if (loss_cnt < 0) {
>>>>>>                  dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>>>>>>                          loss_cnt);
>>>>>>                  serial_omap_restore_context(up);
>>>>>>          } else if (up->context_loss_cnt != loss_cnt) {
>>>>>>                  serial_omap_restore_context(up);
>>>>>>          }
>>>>>> -----
>>>>>>
>>>>>> I am still working on why a serial_omap_restore_context() could
>>>>>> have caused console to die. I will work with Sourav on this and
>>>>>> post the fixes for both issue 1 and issue2 once its clear on whats
>>>>>> really causing issue 2.
>>>>>
>>>>> That's because we don't have the omap specific pdata callbacks for
>>>>> context loss any longer. We may be able to detect when the context
>>>>> was really lost in the serial driver, and only then call the
>>>>> serial_omap_restore_context().
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>
>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>> but from what I see with omap serial, there is no save context done as part of
>> ->runtime_suspend.
>
> right, because context is "saved" in set_termios. probe() will get
> called much before set_termios() has a chance to run, right ?
>
> Same problem will trigger in that case.
>
> I still think patch below is necessary
>
>>> (completely untested, didn't even try to compile, just to illustrate)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>> index 7341eff..d8dca68 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>   	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>   		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>   		postsetup_state = _HWMOD_STATE_ENABLED;
>>> +
>>> +		/* tell pm_runtime this device is already active */
>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>> +	} else {
>>> +		/* tell pm_runtime this device is trully suspended */
>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>   	}
>>>
>>>   	if (postsetup_state == _HWMOD_STATE_IDLE)
>

This will not work - _setup_postsetup() is called from core_initcall 
level and OMAP devices have not been created at this moment yet 
(of_platform_populate() is called from
customize_machine->init_machine->omap_generic_init() at arch_initcall time)

More over, I don't recommend to depend on hwmod->od field - it's been 
created to support OPPs and it's obsolete now in case of DT use.

Seems, This issue need to be handled in driver for DT boot use case, 
possibly cmdline need to be parsed in the same way as it's done in
omap_serial_early_init().

Regards,
-grygorii

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-09 18:59                             ` Grygorii Strashko
@ 2013-07-09 19:41                               ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-09 19:41 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: balbi, Rajendra Nayak, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

Hi,

On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
> >>>Imagine the device is marked as suspended even though it's fully enabled
> >>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>your context structure is all zeroes (context has never been saved
> >>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>->runtime_resume() will get called, which will restore context,
> >>>essentially undoing anything which was configured by u-boot.
> >>
> >>This could be a problem for drivers which do a save context in ->runtime_suspend()
> >>but from what I see with omap serial, there is no save context done as part of
> >>->runtime_suspend.
> >
> >right, because context is "saved" in set_termios. probe() will get
> >called much before set_termios() has a chance to run, right ?
> >
> >Same problem will trigger in that case.
> >
> >I still think patch below is necessary
> >
> >>>(completely untested, didn't even try to compile, just to illustrate)
> >>>
> >>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> >>>index 7341eff..d8dca68 100644
> >>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>>  		postsetup_state = _HWMOD_STATE_ENABLED;
> >>>+
> >>>+		/* tell pm_runtime this device is already active */
> >>>+		pm_runtime_set_active(&oh->od->pdev->dev);
> >>>+	} else {
> >>>+		/* tell pm_runtime this device is trully suspended */
> >>>+		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>>  	}
> >>>
> >>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> >
> 
> This will not work - _setup_postsetup() is called from core_initcall
> level and OMAP devices have not been created at this moment yet
> (of_platform_populate() is called from
> customize_machine->init_machine->omap_generic_init() at arch_initcall time)

fair enough, but something *like* that needs to be done. If pm_runtime
doesn't know the state of the device by the time pm_runtime_enable() is
called, the wrong assumptions might be made and we will forever have
such problems as our ->runtime_resume() callback being called when it
shouldn't.

> More over, I don't recommend to depend on hwmod->od field - it's been
> created to support OPPs and it's obsolete now in case of DT use.

that's alright, but still we need something similar.

But in any case, if on DT boot that's not used, than *what* uses
HWMOD_INIT_NO_IDLE during DT boot ?

There's a single place in kernel source which checks if
HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.

We, certainly, need a way to tell pm_runtime if the device is active or
suspended by the time we reach our probe() function. Either we assume
*all* devices are active and we blindly call pm_runtime_set_active() for
all devices, or we assume *all* devices are suspended as we call
pm_runtime_set_suspend() for all devices, or we figure out which ones
are active and which are not and call pm_runtime_set_{active,suspend}()
conditionally.

> Seems, This issue need to be handled in driver for DT boot use case,
> possibly cmdline need to be parsed in the same way as it's done in
> omap_serial_early_init().

so you want *every* single driver to parse their own cmdline ? How big
would the cmdline become ? This makes no sense.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-09 19:41                               ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-09 19:41 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
> >>>Imagine the device is marked as suspended even though it's fully enabled
> >>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>your context structure is all zeroes (context has never been saved
> >>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>->runtime_resume() will get called, which will restore context,
> >>>essentially undoing anything which was configured by u-boot.
> >>
> >>This could be a problem for drivers which do a save context in ->runtime_suspend()
> >>but from what I see with omap serial, there is no save context done as part of
> >>->runtime_suspend.
> >
> >right, because context is "saved" in set_termios. probe() will get
> >called much before set_termios() has a chance to run, right ?
> >
> >Same problem will trigger in that case.
> >
> >I still think patch below is necessary
> >
> >>>(completely untested, didn't even try to compile, just to illustrate)
> >>>
> >>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> >>>index 7341eff..d8dca68 100644
> >>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>>  		postsetup_state = _HWMOD_STATE_ENABLED;
> >>>+
> >>>+		/* tell pm_runtime this device is already active */
> >>>+		pm_runtime_set_active(&oh->od->pdev->dev);
> >>>+	} else {
> >>>+		/* tell pm_runtime this device is trully suspended */
> >>>+		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>>  	}
> >>>
> >>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> >
> 
> This will not work - _setup_postsetup() is called from core_initcall
> level and OMAP devices have not been created at this moment yet
> (of_platform_populate() is called from
> customize_machine->init_machine->omap_generic_init() at arch_initcall time)

fair enough, but something *like* that needs to be done. If pm_runtime
doesn't know the state of the device by the time pm_runtime_enable() is
called, the wrong assumptions might be made and we will forever have
such problems as our ->runtime_resume() callback being called when it
shouldn't.

> More over, I don't recommend to depend on hwmod->od field - it's been
> created to support OPPs and it's obsolete now in case of DT use.

that's alright, but still we need something similar.

But in any case, if on DT boot that's not used, than *what* uses
HWMOD_INIT_NO_IDLE during DT boot ?

There's a single place in kernel source which checks if
HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.

We, certainly, need a way to tell pm_runtime if the device is active or
suspended by the time we reach our probe() function. Either we assume
*all* devices are active and we blindly call pm_runtime_set_active() for
all devices, or we assume *all* devices are suspended as we call
pm_runtime_set_suspend() for all devices, or we figure out which ones
are active and which are not and call pm_runtime_set_{active,suspend}()
conditionally.

> Seems, This issue need to be handled in driver for DT boot use case,
> possibly cmdline need to be parsed in the same way as it's done in
> omap_serial_early_init().

so you want *every* single driver to parse their own cmdline ? How big
would the cmdline become ? This makes no sense.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130709/d9ed7f62/attachment.sig>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-08 13:35                       ` Felipe Balbi
@ 2013-07-10  8:22                         ` Kevin Hilman
  -1 siblings, 0 replies; 96+ messages in thread
From: Kevin Hilman @ 2013-07-10  8:22 UTC (permalink / raw)
  To: balbi
  Cc: Rajendra Nayak, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

Felipe Balbi <balbi@ti.com> writes:

> Hi,
>
> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>> >>>>>> of -1 for the serial driver?
>> >>>>>>
>> >>>>>
>> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>> >>>
>> >>> OK
>> >>
>> >> Issue 2: Causing boot to stop when serial driver is initialized.
>> >> (After Issue 1 is fixed)
>> >>
>> >> I could narrow this down to the change done to return -EINVAL
>> >> instead of 0 in serial_omap_get_context_loss_count() as part of
>> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>> >> Fix device tree based PM runtime"
>> >>
>> >> What this change in turn seems to do is cause a
>> >> serial_omap_restore_context() to get called as part of
>> >> serial_omap_runtime_resume() which was not the case when
>> >> serial_omap_get_context_loss_count() returned 0
>> >>
>> >> from serial_omap_runtime_resume():
>> >> -----
>> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
>> >>
>> >>         if (loss_cnt < 0) {
>> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>> >>                         loss_cnt);
>> >>                 serial_omap_restore_context(up);
>> >>         } else if (up->context_loss_cnt != loss_cnt) {
>> >>                 serial_omap_restore_context(up);
>> >>         }
>> >> -----
>> >>
>> >> I am still working on why a serial_omap_restore_context() could
>> >> have caused console to die. I will work with Sourav on this and
>> >> post the fixes for both issue 1 and issue2 once its clear on whats
>> >> really causing issue 2.
>> > 
>> > That's because we don't have the omap specific pdata callbacks for
>> > context loss any longer. We may be able to detect when the context
>> > was really lost in the serial driver, and only then call the
>> > serial_omap_restore_context().
>> 
>> Right, but calling serial_omap_restore_context() even when the context
>> is not lost, should not ideally cause an issue.
>
> it does in one condition. If context hasn't been saved before. And that
> can happen in the case of wrong pm runtime status for that device.
>
> Imagine the device is marked as suspended even though it's fully enabled
> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> your context structure is all zeroes (context has never been saved
> before) then when you call pm_runtime_get_sync() on probe() your
> ->runtime_resume() will get called, which will restore context,
> essentially undoing anything which was configured by u-boot.
>
> Am I missing something ?

You're right, the _set_active() is crucial in the case when we prevent
the console UART from idling during boot (though that shouldn't be
happening in mainline unless the fix for "Issue 1" is done.)

Kevin

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10  8:22                         ` Kevin Hilman
  0 siblings, 0 replies; 96+ messages in thread
From: Kevin Hilman @ 2013-07-10  8:22 UTC (permalink / raw)
  To: linux-arm-kernel

Felipe Balbi <balbi@ti.com> writes:

> Hi,
>
> On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
>> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
>> >>>>>> of -1 for the serial driver?
>> >>>>>>
>> >>>>>
>> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
>> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
>> >>>
>> >>> OK
>> >>
>> >> Issue 2: Causing boot to stop when serial driver is initialized.
>> >> (After Issue 1 is fixed)
>> >>
>> >> I could narrow this down to the change done to return -EINVAL
>> >> instead of 0 in serial_omap_get_context_loss_count() as part of
>> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
>> >> Fix device tree based PM runtime"
>> >>
>> >> What this change in turn seems to do is cause a
>> >> serial_omap_restore_context() to get called as part of
>> >> serial_omap_runtime_resume() which was not the case when
>> >> serial_omap_get_context_loss_count() returned 0
>> >>
>> >> from serial_omap_runtime_resume():
>> >> -----
>> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
>> >>
>> >>         if (loss_cnt < 0) {
>> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
>> >>                         loss_cnt);
>> >>                 serial_omap_restore_context(up);
>> >>         } else if (up->context_loss_cnt != loss_cnt) {
>> >>                 serial_omap_restore_context(up);
>> >>         }
>> >> -----
>> >>
>> >> I am still working on why a serial_omap_restore_context() could
>> >> have caused console to die. I will work with Sourav on this and
>> >> post the fixes for both issue 1 and issue2 once its clear on whats
>> >> really causing issue 2.
>> > 
>> > That's because we don't have the omap specific pdata callbacks for
>> > context loss any longer. We may be able to detect when the context
>> > was really lost in the serial driver, and only then call the
>> > serial_omap_restore_context().
>> 
>> Right, but calling serial_omap_restore_context() even when the context
>> is not lost, should not ideally cause an issue.
>
> it does in one condition. If context hasn't been saved before. And that
> can happen in the case of wrong pm runtime status for that device.
>
> Imagine the device is marked as suspended even though it's fully enabled
> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> your context structure is all zeroes (context has never been saved
> before) then when you call pm_runtime_get_sync() on probe() your
> ->runtime_resume() will get called, which will restore context,
> essentially undoing anything which was configured by u-boot.
>
> Am I missing something ?

You're right, the _set_active() is crucial in the case when we prevent
the console UART from idling during boot (though that shouldn't be
happening in mainline unless the fix for "Issue 1" is done.)

Kevin

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10  8:22                         ` Kevin Hilman
@ 2013-07-10 12:10                           ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-10 12:10 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: balbi, Rajendra Nayak, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

* Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> Felipe Balbi <balbi@ti.com> writes:
> 
> > Hi,
> >
> > On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >> >>>>>> of -1 for the serial driver?
> >> >>>>>>
> >> >>>>>
> >> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >> >>>
> >> >>> OK
> >> >>
> >> >> Issue 2: Causing boot to stop when serial driver is initialized.
> >> >> (After Issue 1 is fixed)
> >> >>
> >> >> I could narrow this down to the change done to return -EINVAL
> >> >> instead of 0 in serial_omap_get_context_loss_count() as part of
> >> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >> >> Fix device tree based PM runtime"
> >> >>
> >> >> What this change in turn seems to do is cause a
> >> >> serial_omap_restore_context() to get called as part of
> >> >> serial_omap_runtime_resume() which was not the case when
> >> >> serial_omap_get_context_loss_count() returned 0
> >> >>
> >> >> from serial_omap_runtime_resume():
> >> >> -----
> >> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >> >>
> >> >>         if (loss_cnt < 0) {
> >> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >> >>                         loss_cnt);
> >> >>                 serial_omap_restore_context(up);
> >> >>         } else if (up->context_loss_cnt != loss_cnt) {
> >> >>                 serial_omap_restore_context(up);
> >> >>         }
> >> >> -----
> >> >>
> >> >> I am still working on why a serial_omap_restore_context() could
> >> >> have caused console to die. I will work with Sourav on this and
> >> >> post the fixes for both issue 1 and issue2 once its clear on whats
> >> >> really causing issue 2.
> >> > 
> >> > That's because we don't have the omap specific pdata callbacks for
> >> > context loss any longer. We may be able to detect when the context
> >> > was really lost in the serial driver, and only then call the
> >> > serial_omap_restore_context().
> >> 
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> >
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> >
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> >
> > Am I missing something ?
> 
> You're right, the _set_active() is crucial in the case when we prevent
> the console UART from idling during boot (though that shouldn't be
> happening in mainline unless the fix for "Issue 1" is done.)

OK so how should we fix this?

If the problem is hwmod automatically resetting things early while
earlycon is running, then the reset should happen later.

If the problem is omap-serial.c idling things while earlycon is
running, then omap-serial.c should be fixed.

In any case we want mach-omap2/serial.c out of the way completely
for DT based booting.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 12:10                           ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-10 12:10 UTC (permalink / raw)
  To: linux-arm-kernel

* Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> Felipe Balbi <balbi@ti.com> writes:
> 
> > Hi,
> >
> > On Mon, Jul 08, 2013 at 06:50:01PM +0530, Rajendra Nayak wrote:
> >> >>>>>> I wonder if this is because the timeouts get now initialized to 0 instead
> >> >>>>>> of -1 for the serial driver?
> >> >>>>>>
> >> >>>>>
> >> >>>>> You meant initialized to -1, right? There's an additional check for timeout being 0. Unless i
> >> >>>>> am missing something DT-boot will start off with timeout set to 0 and then get forced to -1.
> >> >>>
> >> >>> OK
> >> >>
> >> >> Issue 2: Causing boot to stop when serial driver is initialized.
> >> >> (After Issue 1 is fixed)
> >> >>
> >> >> I could narrow this down to the change done to return -EINVAL
> >> >> instead of 0 in serial_omap_get_context_loss_count() as part of
> >> >> commit 'a630fbfbb1beeffc5bbe542a7986bf2068874633' "serial: omap:
> >> >> Fix device tree based PM runtime"
> >> >>
> >> >> What this change in turn seems to do is cause a
> >> >> serial_omap_restore_context() to get called as part of
> >> >> serial_omap_runtime_resume() which was not the case when
> >> >> serial_omap_get_context_loss_count() returned 0
> >> >>
> >> >> from serial_omap_runtime_resume():
> >> >> -----
> >> >>         int loss_cnt = serial_omap_get_context_loss_count(up);
> >> >>
> >> >>         if (loss_cnt < 0) {
> >> >>                 dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> >> >>                         loss_cnt);
> >> >>                 serial_omap_restore_context(up);
> >> >>         } else if (up->context_loss_cnt != loss_cnt) {
> >> >>                 serial_omap_restore_context(up);
> >> >>         }
> >> >> -----
> >> >>
> >> >> I am still working on why a serial_omap_restore_context() could
> >> >> have caused console to die. I will work with Sourav on this and
> >> >> post the fixes for both issue 1 and issue2 once its clear on whats
> >> >> really causing issue 2.
> >> > 
> >> > That's because we don't have the omap specific pdata callbacks for
> >> > context loss any longer. We may be able to detect when the context
> >> > was really lost in the serial driver, and only then call the
> >> > serial_omap_restore_context().
> >> 
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> >
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> >
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> >
> > Am I missing something ?
> 
> You're right, the _set_active() is crucial in the case when we prevent
> the console UART from idling during boot (though that shouldn't be
> happening in mainline unless the fix for "Issue 1" is done.)

OK so how should we fix this?

If the problem is hwmod automatically resetting things early while
earlycon is running, then the reset should happen later.

If the problem is omap-serial.c idling things while earlycon is
running, then omap-serial.c should be fixed.

In any case we want mach-omap2/serial.c out of the way completely
for DT based booting.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-09 19:41                               ` Felipe Balbi
@ 2013-07-10 12:16                                 ` Grygorii Strashko
  -1 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-10 12:16 UTC (permalink / raw)
  To: balbi
  Cc: Rajendra Nayak, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

On 07/09/2013 10:41 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
>>>>> Imagine the device is marked as suspended even though it's fully enabled
>>>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>>>> your context structure is all zeroes (context has never been saved
>>>>> before) then when you call pm_runtime_get_sync() on probe() your
>>>>> ->runtime_resume() will get called, which will restore context,
>>>>> essentially undoing anything which was configured by u-boot.
>>>>
>>>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>>>> but from what I see with omap serial, there is no save context done as part of
>>>> ->runtime_suspend.
>>>
>>> right, because context is "saved" in set_termios. probe() will get
>>> called much before set_termios() has a chance to run, right ?
>>>
>>> Same problem will trigger in that case.
>>>
>>> I still think patch below is necessary
>>>
>>>>> (completely untested, didn't even try to compile, just to illustrate)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>>>> index 7341eff..d8dca68 100644
>>>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>>>   	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>>>   		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>>>   		postsetup_state = _HWMOD_STATE_ENABLED;
>>>>> +
>>>>> +		/* tell pm_runtime this device is already active */
>>>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>>>> +	} else {
>>>>> +		/* tell pm_runtime this device is trully suspended */
>>>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>>>   	}
>>>>>
>>>>>   	if (postsetup_state == _HWMOD_STATE_IDLE)
>>>
>>
>> This will not work - _setup_postsetup() is called from core_initcall
>> level and OMAP devices have not been created at this moment yet
>> (of_platform_populate() is called from
>> customize_machine->init_machine->omap_generic_init() at arch_initcall time)
>
> fair enough, but something *like* that needs to be done. If pm_runtime
> doesn't know the state of the device by the time pm_runtime_enable() is
> called, the wrong assumptions might be made and we will forever have
> such problems as our ->runtime_resume() callback being called when it
> shouldn't.
>
>> More over, I don't recommend to depend on hwmod->od field - it's been
>> created to support OPPs and it's obsolete now in case of DT use.
>
> that's alright, but still we need something similar.
>
> But in any case, if on DT boot that's not used, than *what* uses
> HWMOD_INIT_NO_IDLE during DT boot ?
>
> There's a single place in kernel source which checks if
> HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
>
> We, certainly, need a way to tell pm_runtime if the device is active or
> suspended by the time we reach our probe() function. Either we assume
> *all* devices are active and we blindly call pm_runtime_set_active() for
> all devices, or we assume *all* devices are suspended as we call
> pm_runtime_set_suspend() for all devices, or we figure out which ones
> are active and which are not and call pm_runtime_set_{active,suspend}()
> conditionally.
>
>> Seems, This issue need to be handled in driver for DT boot use case,
>> possibly cmdline need to be parsed in the same way as it's done in
>> omap_serial_early_init().
>
> so you want *every* single driver to parse their own cmdline ? How big
> would the cmdline become ? This makes no sense.
>

Agree here. Seems there two similar issues:
- this one with omap_serial
- GPIO reset issue http://www.spinics.net/lists/linux-omap/msg84186.html
   (similar issue is observed on OMAP4460+TPS6236x)

And I think, that HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags can't 
be treated as
SoC (IP) specific parameters any more - they should be board specific.

I think, some kind of board_layout {} DT definition need to be created 
to solve these issues (just an idea). For example:

Board DTS file:
board_layout {
  ti,hwmods-init-no-reset = "gpio1", "uart3";
  ti,hwmods-init-no-idle = "uart3";
}

Then above DT parameters can be used in omap_hwmod_setup_all()->_setup()
and omap_device_build_from_dt().
- omap_hwmod_setup_all()->_setup() will configure hwmod's flags
- omap_device_build_from_dt() will check for HWMOD_INIT_NO_IDLE and
   call pm_runtime_set_active() if needed (this is the valid place for that)

NOTE. "ti,hwmods-init-no-reset" and "ti,hwmods-init-no-idle" can't be 
defined per device, because HWMOD framework will work 
(init/reset/setup/idle) with IP even if corresponding IP is not defined 
in DT.

More over, board_layout{} section can be used to define some common for 
OMAP2+ boards properties or enable/disable PM features, like:
- Setup clksetup/clkshoutdown time for oscillator
- enable/disable OFF-mode

Regards,
-grygorii


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 12:16                                 ` Grygorii Strashko
  0 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-10 12:16 UTC (permalink / raw)
  To: linux-arm-kernel

On 07/09/2013 10:41 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 09:59:28PM +0300, Grygorii Strashko wrote:
>>>>> Imagine the device is marked as suspended even though it's fully enabled
>>>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>>>> your context structure is all zeroes (context has never been saved
>>>>> before) then when you call pm_runtime_get_sync() on probe() your
>>>>> ->runtime_resume() will get called, which will restore context,
>>>>> essentially undoing anything which was configured by u-boot.
>>>>
>>>> This could be a problem for drivers which do a save context in ->runtime_suspend()
>>>> but from what I see with omap serial, there is no save context done as part of
>>>> ->runtime_suspend.
>>>
>>> right, because context is "saved" in set_termios. probe() will get
>>> called much before set_termios() has a chance to run, right ?
>>>
>>> Same problem will trigger in that case.
>>>
>>> I still think patch below is necessary
>>>
>>>>> (completely untested, didn't even try to compile, just to illustrate)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
>>>>> index 7341eff..d8dca68 100644
>>>>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>>>>> @@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
>>>>>   	    (postsetup_state == _HWMOD_STATE_IDLE)) {
>>>>>   		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
>>>>>   		postsetup_state = _HWMOD_STATE_ENABLED;
>>>>> +
>>>>> +		/* tell pm_runtime this device is already active */
>>>>> +		pm_runtime_set_active(&oh->od->pdev->dev);
>>>>> +	} else {
>>>>> +		/* tell pm_runtime this device is trully suspended */
>>>>> +		pm_runtime_set_suspended(&oh->od->pdev->dev);
>>>>>   	}
>>>>>
>>>>>   	if (postsetup_state == _HWMOD_STATE_IDLE)
>>>
>>
>> This will not work - _setup_postsetup() is called from core_initcall
>> level and OMAP devices have not been created at this moment yet
>> (of_platform_populate() is called from
>> customize_machine->init_machine->omap_generic_init() at arch_initcall time)
>
> fair enough, but something *like* that needs to be done. If pm_runtime
> doesn't know the state of the device by the time pm_runtime_enable() is
> called, the wrong assumptions might be made and we will forever have
> such problems as our ->runtime_resume() callback being called when it
> shouldn't.
>
>> More over, I don't recommend to depend on hwmod->od field - it's been
>> created to support OPPs and it's obsolete now in case of DT use.
>
> that's alright, but still we need something similar.
>
> But in any case, if on DT boot that's not used, than *what* uses
> HWMOD_INIT_NO_IDLE during DT boot ?
>
> There's a single place in kernel source which checks if
> HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
>
> We, certainly, need a way to tell pm_runtime if the device is active or
> suspended by the time we reach our probe() function. Either we assume
> *all* devices are active and we blindly call pm_runtime_set_active() for
> all devices, or we assume *all* devices are suspended as we call
> pm_runtime_set_suspend() for all devices, or we figure out which ones
> are active and which are not and call pm_runtime_set_{active,suspend}()
> conditionally.
>
>> Seems, This issue need to be handled in driver for DT boot use case,
>> possibly cmdline need to be parsed in the same way as it's done in
>> omap_serial_early_init().
>
> so you want *every* single driver to parse their own cmdline ? How big
> would the cmdline become ? This makes no sense.
>

Agree here. Seems there two similar issues:
- this one with omap_serial
- GPIO reset issue http://www.spinics.net/lists/linux-omap/msg84186.html
   (similar issue is observed on OMAP4460+TPS6236x)

And I think, that HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags can't 
be treated as
SoC (IP) specific parameters any more - they should be board specific.

I think, some kind of board_layout {} DT definition need to be created 
to solve these issues (just an idea). For example:

Board DTS file:
board_layout {
  ti,hwmods-init-no-reset = "gpio1", "uart3";
  ti,hwmods-init-no-idle = "uart3";
}

Then above DT parameters can be used in omap_hwmod_setup_all()->_setup()
and omap_device_build_from_dt().
- omap_hwmod_setup_all()->_setup() will configure hwmod's flags
- omap_device_build_from_dt() will check for HWMOD_INIT_NO_IDLE and
   call pm_runtime_set_active() if needed (this is the valid place for that)

NOTE. "ti,hwmods-init-no-reset" and "ti,hwmods-init-no-idle" can't be 
defined per device, because HWMOD framework will work 
(init/reset/setup/idle) with IP even if corresponding IP is not defined 
in DT.

More over, board_layout{} section can be used to define some common for 
OMAP2+ boards properties or enable/disable PM features, like:
- Setup clksetup/clkshoutdown time for oscillator
- enable/disable OFF-mode

Regards,
-grygorii

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 12:16                                 ` Grygorii Strashko
@ 2013-07-10 12:25                                   ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-10 12:25 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: balbi, Rajendra Nayak, Tony Lindgren, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 4569 bytes --]

Hi,

On Wed, Jul 10, 2013 at 03:16:54PM +0300, Grygorii Strashko wrote:
> >>>>>Imagine the device is marked as suspended even though it's fully enabled
> >>>>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>>>your context structure is all zeroes (context has never been saved
> >>>>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>>>->runtime_resume() will get called, which will restore context,
> >>>>>essentially undoing anything which was configured by u-boot.
> >>>>
> >>>>This could be a problem for drivers which do a save context in ->runtime_suspend()
> >>>>but from what I see with omap serial, there is no save context done as part of
> >>>>->runtime_suspend.
> >>>
> >>>right, because context is "saved" in set_termios. probe() will get
> >>>called much before set_termios() has a chance to run, right ?
> >>>
> >>>Same problem will trigger in that case.
> >>>
> >>>I still think patch below is necessary
> >>>
> >>>>>(completely untested, didn't even try to compile, just to illustrate)
> >>>>>
> >>>>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>index 7341eff..d8dca68 100644
> >>>>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >>>>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>>>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>>>>  		postsetup_state = _HWMOD_STATE_ENABLED;
> >>>>>+
> >>>>>+		/* tell pm_runtime this device is already active */
> >>>>>+		pm_runtime_set_active(&oh->od->pdev->dev);
> >>>>>+	} else {
> >>>>>+		/* tell pm_runtime this device is trully suspended */
> >>>>>+		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>>>>  	}
> >>>>>
> >>>>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> >>>
> >>
> >>This will not work - _setup_postsetup() is called from core_initcall
> >>level and OMAP devices have not been created at this moment yet
> >>(of_platform_populate() is called from
> >>customize_machine->init_machine->omap_generic_init() at arch_initcall time)
> >
> >fair enough, but something *like* that needs to be done. If pm_runtime
> >doesn't know the state of the device by the time pm_runtime_enable() is
> >called, the wrong assumptions might be made and we will forever have
> >such problems as our ->runtime_resume() callback being called when it
> >shouldn't.
> >
> >>More over, I don't recommend to depend on hwmod->od field - it's been
> >>created to support OPPs and it's obsolete now in case of DT use.
> >
> >that's alright, but still we need something similar.
> >
> >But in any case, if on DT boot that's not used, than *what* uses
> >HWMOD_INIT_NO_IDLE during DT boot ?
> >
> >There's a single place in kernel source which checks if
> >HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
> >
> >We, certainly, need a way to tell pm_runtime if the device is active or
> >suspended by the time we reach our probe() function. Either we assume
> >*all* devices are active and we blindly call pm_runtime_set_active() for
> >all devices, or we assume *all* devices are suspended as we call
> >pm_runtime_set_suspend() for all devices, or we figure out which ones
> >are active and which are not and call pm_runtime_set_{active,suspend}()
> >conditionally.
> >
> >>Seems, This issue need to be handled in driver for DT boot use case,
> >>possibly cmdline need to be parsed in the same way as it's done in
> >>omap_serial_early_init().
> >
> >so you want *every* single driver to parse their own cmdline ? How big
> >would the cmdline become ? This makes no sense.
> >
> 
> Agree here. Seems there two similar issues:
> - this one with omap_serial
> - GPIO reset issue http://www.spinics.net/lists/linux-omap/msg84186.html
>   (similar issue is observed on OMAP4460+TPS6236x)
> 
> And I think, that HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
> can't be treated as
> SoC (IP) specific parameters any more - they should be board specific.
> 
> I think, some kind of board_layout {} DT definition need to be
> created to solve these issues (just an idea). For example:
> 
> Board DTS file:
> board_layout {
>  ti,hwmods-init-no-reset = "gpio1", "uart3";
>  ti,hwmods-init-no-idle = "uart3";
> }

nah... if we go down the path of passing this info via DT, all you need
to pass is some information if the IP should be reset/idled or not
during initialization.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 12:25                                   ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-10 12:25 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, Jul 10, 2013 at 03:16:54PM +0300, Grygorii Strashko wrote:
> >>>>>Imagine the device is marked as suspended even though it's fully enabled
> >>>>>(it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> >>>>>your context structure is all zeroes (context has never been saved
> >>>>>before) then when you call pm_runtime_get_sync() on probe() your
> >>>>>->runtime_resume() will get called, which will restore context,
> >>>>>essentially undoing anything which was configured by u-boot.
> >>>>
> >>>>This could be a problem for drivers which do a save context in ->runtime_suspend()
> >>>>but from what I see with omap serial, there is no save context done as part of
> >>>>->runtime_suspend.
> >>>
> >>>right, because context is "saved" in set_termios. probe() will get
> >>>called much before set_termios() has a chance to run, right ?
> >>>
> >>>Same problem will trigger in that case.
> >>>
> >>>I still think patch below is necessary
> >>>
> >>>>>(completely untested, didn't even try to compile, just to illustrate)
> >>>>>
> >>>>>diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>index 7341eff..d8dca68 100644
> >>>>>--- a/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>+++ b/arch/arm/mach-omap2/omap_hwmod.c
> >>>>>@@ -2559,6 +2559,12 @@ static void __init _setup_postsetup(struct omap_hwmod *oh)
> >>>>>  	    (postsetup_state == _HWMOD_STATE_IDLE)) {
> >>>>>  		oh->_int_flags |= _HWMOD_SKIP_ENABLE;
> >>>>>  		postsetup_state = _HWMOD_STATE_ENABLED;
> >>>>>+
> >>>>>+		/* tell pm_runtime this device is already active */
> >>>>>+		pm_runtime_set_active(&oh->od->pdev->dev);
> >>>>>+	} else {
> >>>>>+		/* tell pm_runtime this device is trully suspended */
> >>>>>+		pm_runtime_set_suspended(&oh->od->pdev->dev);
> >>>>>  	}
> >>>>>
> >>>>>  	if (postsetup_state == _HWMOD_STATE_IDLE)
> >>>
> >>
> >>This will not work - _setup_postsetup() is called from core_initcall
> >>level and OMAP devices have not been created at this moment yet
> >>(of_platform_populate() is called from
> >>customize_machine->init_machine->omap_generic_init() at arch_initcall time)
> >
> >fair enough, but something *like* that needs to be done. If pm_runtime
> >doesn't know the state of the device by the time pm_runtime_enable() is
> >called, the wrong assumptions might be made and we will forever have
> >such problems as our ->runtime_resume() callback being called when it
> >shouldn't.
> >
> >>More over, I don't recommend to depend on hwmod->od field - it's been
> >>created to support OPPs and it's obsolete now in case of DT use.
> >
> >that's alright, but still we need something similar.
> >
> >But in any case, if on DT boot that's not used, than *what* uses
> >HWMOD_INIT_NO_IDLE during DT boot ?
> >
> >There's a single place in kernel source which checks if
> >HWMOD_INIT_NO_IDLE is set, and that's the place which I patched.
> >
> >We, certainly, need a way to tell pm_runtime if the device is active or
> >suspended by the time we reach our probe() function. Either we assume
> >*all* devices are active and we blindly call pm_runtime_set_active() for
> >all devices, or we assume *all* devices are suspended as we call
> >pm_runtime_set_suspend() for all devices, or we figure out which ones
> >are active and which are not and call pm_runtime_set_{active,suspend}()
> >conditionally.
> >
> >>Seems, This issue need to be handled in driver for DT boot use case,
> >>possibly cmdline need to be parsed in the same way as it's done in
> >>omap_serial_early_init().
> >
> >so you want *every* single driver to parse their own cmdline ? How big
> >would the cmdline become ? This makes no sense.
> >
> 
> Agree here. Seems there two similar issues:
> - this one with omap_serial
> - GPIO reset issue http://www.spinics.net/lists/linux-omap/msg84186.html
>   (similar issue is observed on OMAP4460+TPS6236x)
> 
> And I think, that HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET flags
> can't be treated as
> SoC (IP) specific parameters any more - they should be board specific.
> 
> I think, some kind of board_layout {} DT definition need to be
> created to solve these issues (just an idea). For example:
> 
> Board DTS file:
> board_layout {
>  ti,hwmods-init-no-reset = "gpio1", "uart3";
>  ti,hwmods-init-no-idle = "uart3";
> }

nah... if we go down the path of passing this info via DT, all you need
to pass is some information if the IP should be reset/idled or not
during initialization.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130710/dcf07749/attachment.sig>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 12:10                           ` Tony Lindgren
@ 2013-07-10 12:27                             ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-10 12:27 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: balbi, Rajendra Nayak, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

* Tony Lindgren <tony@atomide.com> [130710 05:17]:
> * Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> 
> If the problem is omap-serial.c idling things while earlycon is
> running, then omap-serial.c should be fixed.

If this is the case, then delaying the idling in omap-serial.c
should take care of the issue as earlycon gets disabled when
the real console has been initialized.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 12:27                             ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-10 12:27 UTC (permalink / raw)
  To: linux-arm-kernel

* Tony Lindgren <tony@atomide.com> [130710 05:17]:
> * Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> 
> If the problem is omap-serial.c idling things while earlycon is
> running, then omap-serial.c should be fixed.

If this is the case, then delaying the idling in omap-serial.c
should take care of the issue as earlycon gets disabled when
the real console has been initialized.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10  8:22                         ` Kevin Hilman
@ 2013-07-10 14:26                           ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-10 14:26 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: balbi, Rajendra Nayak, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

* Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> Felipe Balbi <balbi@ti.com> writes:
> >> 
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> >
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> >
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> >
> > Am I missing something ?
> 
> You're right, the _set_active() is crucial in the case when we prevent
> the console UART from idling during boot (though that shouldn't be
> happening in mainline unless the fix for "Issue 1" is done.)

Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.

After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
works for me. We could also check for some combination of the context
save registers being NULL if somebody has a good idea which ones
should never be 0.

Regards,

Tony


--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -161,6 +161,7 @@ struct uart_omap_port {
 	u32			calc_latency;
 	struct work_struct	qos_work;
 	struct pinctrl		*pins;
+	bool			initialized;
 	bool			is_suspending;
 };
 
@@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
+	up->initialized = true;
+
 	return 0;
 
 err_add_port:
@@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
 #ifdef CONFIG_PM_RUNTIME
 static void serial_omap_restore_context(struct uart_omap_port *up)
 {
+	if (!up->initialized)
+		return;
+
 	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
 		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
 	else

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 14:26                           ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-10 14:26 UTC (permalink / raw)
  To: linux-arm-kernel

* Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> Felipe Balbi <balbi@ti.com> writes:
> >> 
> >> Right, but calling serial_omap_restore_context() even when the context
> >> is not lost, should not ideally cause an issue.
> >
> > it does in one condition. If context hasn't been saved before. And that
> > can happen in the case of wrong pm runtime status for that device.
> >
> > Imagine the device is marked as suspended even though it's fully enabled
> > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > your context structure is all zeroes (context has never been saved
> > before) then when you call pm_runtime_get_sync() on probe() your
> > ->runtime_resume() will get called, which will restore context,
> > essentially undoing anything which was configured by u-boot.
> >
> > Am I missing something ?
> 
> You're right, the _set_active() is crucial in the case when we prevent
> the console UART from idling during boot (though that shouldn't be
> happening in mainline unless the fix for "Issue 1" is done.)

Felipe is right, looks like all we need is to check if context is
initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.

After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
works for me. We could also check for some combination of the context
save registers being NULL if somebody has a good idea which ones
should never be 0.

Regards,

Tony


--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -161,6 +161,7 @@ struct uart_omap_port {
 	u32			calc_latency;
 	struct work_struct	qos_work;
 	struct pinctrl		*pins;
+	bool			initialized;
 	bool			is_suspending;
 };
 
@@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
+	up->initialized = true;
+
 	return 0;
 
 err_add_port:
@@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
 #ifdef CONFIG_PM_RUNTIME
 static void serial_omap_restore_context(struct uart_omap_port *up)
 {
+	if (!up->initialized)
+		return;
+
 	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
 		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
 	else

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 14:26                           ` Tony Lindgren
@ 2013-07-10 16:07                             ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-10 16:07 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Kevin Hilman, balbi, Rajendra Nayak, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 4934 bytes --]

Hi,

On Wed, Jul 10, 2013 at 07:26:34AM -0700, Tony Lindgren wrote:
> * Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> > Felipe Balbi <balbi@ti.com> writes:
> > >> 
> > >> Right, but calling serial_omap_restore_context() even when the context
> > >> is not lost, should not ideally cause an issue.
> > >
> > > it does in one condition. If context hasn't been saved before. And that
> > > can happen in the case of wrong pm runtime status for that device.
> > >
> > > Imagine the device is marked as suspended even though it's fully enabled
> > > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > > your context structure is all zeroes (context has never been saved
> > > before) then when you call pm_runtime_get_sync() on probe() your
> > > ->runtime_resume() will get called, which will restore context,
> > > essentially undoing anything which was configured by u-boot.
> > >
> > > Am I missing something ?
> > 
> > You're right, the _set_active() is crucial in the case when we prevent
> > the console UART from idling during boot (though that shouldn't be
> > happening in mainline unless the fix for "Issue 1" is done.)
> 
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> 
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me. We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
> 
> Regards,
> 
> Tony
> 
> 
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
>  	u32			calc_latency;
>  	struct work_struct	qos_work;
>  	struct pinctrl		*pins;
> +	bool			initialized;
>  	bool			is_suspending;
>  };
>  
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>  
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
> +	up->initialized = true;
> +
>  	return 0;
>  
>  err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
>  #ifdef CONFIG_PM_RUNTIME
>  static void serial_omap_restore_context(struct uart_omap_port *up)
>  {
> +	if (!up->initialized)
> +		return;
> +
>  	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
>  		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
>  	else

how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
->runtime_resume() from being called on first pm_runtime_get*() done
during probe.

This is similar to what PCI bus does (if you look at pci_pm_init()).

commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
Author: Felipe Balbi <balbi@ti.com>
Date:   Wed Jul 10 18:50:16 2013 +0300

    arm: omap2plus: unidle devices which are about to probe
    
    in order to make HWMOD and pm_runtime agree on the
    initial state of the device, we will unidle the device
    and call pm_runtime_set_active() to tell pm_runtime
    that the device is really active.
    
    By the time driver's probe() is reached, a call to
    pm_runtime_get_sync() will not cause driver's
    ->runtime_resume() method to be called at first, only
    after a successful ->runtime_suspend().
    
    Signed-off-by: Felipe Balbi <balbi@ti.com>

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index e6d2307..1cedf3a 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev);
+{
+	/*
+	 * if we reach this function, it's because the device is about to be
+	 * probed. In such cases, we will enable the device, and call
+	 * pm_runtime_set_active() so that the device driver and runtime PM
+	 * framework agree on initial state of the device.
+	 */
+	omap_device_enable(pdev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev);
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -192,6 +212,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 16:07                             ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-10 16:07 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, Jul 10, 2013 at 07:26:34AM -0700, Tony Lindgren wrote:
> * Kevin Hilman <khilman@linaro.org> [130710 01:29]:
> > Felipe Balbi <balbi@ti.com> writes:
> > >> 
> > >> Right, but calling serial_omap_restore_context() even when the context
> > >> is not lost, should not ideally cause an issue.
> > >
> > > it does in one condition. If context hasn't been saved before. And that
> > > can happen in the case of wrong pm runtime status for that device.
> > >
> > > Imagine the device is marked as suspended even though it's fully enabled
> > > (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
> > > your context structure is all zeroes (context has never been saved
> > > before) then when you call pm_runtime_get_sync() on probe() your
> > > ->runtime_resume() will get called, which will restore context,
> > > essentially undoing anything which was configured by u-boot.
> > >
> > > Am I missing something ?
> > 
> > You're right, the _set_active() is crucial in the case when we prevent
> > the console UART from idling during boot (though that shouldn't be
> > happening in mainline unless the fix for "Issue 1" is done.)
> 
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> 
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me. We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
> 
> Regards,
> 
> Tony
> 
> 
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
>  	u32			calc_latency;
>  	struct work_struct	qos_work;
>  	struct pinctrl		*pins;
> +	bool			initialized;
>  	bool			is_suspending;
>  };
>  
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>  
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
> +	up->initialized = true;
> +
>  	return 0;
>  
>  err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
>  #ifdef CONFIG_PM_RUNTIME
>  static void serial_omap_restore_context(struct uart_omap_port *up)
>  {
> +	if (!up->initialized)
> +		return;
> +
>  	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
>  		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
>  	else

how about something like below ? It makes omap_device/hwmod and
pm_runtime agree on the initial state of the device and will prevent
->runtime_resume() from being called on first pm_runtime_get*() done
during probe.

This is similar to what PCI bus does (if you look at pci_pm_init()).

commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
Author: Felipe Balbi <balbi@ti.com>
Date:   Wed Jul 10 18:50:16 2013 +0300

    arm: omap2plus: unidle devices which are about to probe
    
    in order to make HWMOD and pm_runtime agree on the
    initial state of the device, we will unidle the device
    and call pm_runtime_set_active() to tell pm_runtime
    that the device is really active.
    
    By the time driver's probe() is reached, a call to
    pm_runtime_get_sync() will not cause driver's
    ->runtime_resume() method to be called at first, only
    after a successful ->runtime_suspend().
    
    Signed-off-by: Felipe Balbi <balbi@ti.com>

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index e6d2307..1cedf3a 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev);
+{
+	/*
+	 * if we reach this function, it's because the device is about to be
+	 * probed. In such cases, we will enable the device, and call
+	 * pm_runtime_set_active() so that the device driver and runtime PM
+	 * framework agree on initial state of the device.
+	 */
+	omap_device_enable(pdev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev);
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -192,6 +212,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130710/5f849a70/attachment.sig>

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 16:07                             ` Felipe Balbi
@ 2013-07-10 16:11                               ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-10 16:11 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Tony Lindgren, Kevin Hilman, Rajendra Nayak, Bedia, Vaibhav,
	linux-omap, linux-arm-kernel, Mark Jackson, Sourav Poddar,
	Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Hi,

On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
> how about something like below ? It makes omap_device/hwmod and
> pm_runtime agree on the initial state of the device and will prevent
> ->runtime_resume() from being called on first pm_runtime_get*() done
> during probe.
> 
> This is similar to what PCI bus does (if you look at pci_pm_init()).
> 
> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
> Author: Felipe Balbi <balbi@ti.com>
> Date:   Wed Jul 10 18:50:16 2013 +0300
> 
>     arm: omap2plus: unidle devices which are about to probe
>     
>     in order to make HWMOD and pm_runtime agree on the
>     initial state of the device, we will unidle the device
>     and call pm_runtime_set_active() to tell pm_runtime
>     that the device is really active.
>     
>     By the time driver's probe() is reached, a call to
>     pm_runtime_get_sync() will not cause driver's
>     ->runtime_resume() method to be called at first, only
>     after a successful ->runtime_suspend().
>     
>     Signed-off-by: Felipe Balbi <balbi@ti.com>

btw, this is RFC, haven't tested at all.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-10 16:11                               ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-10 16:11 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
> how about something like below ? It makes omap_device/hwmod and
> pm_runtime agree on the initial state of the device and will prevent
> ->runtime_resume() from being called on first pm_runtime_get*() done
> during probe.
> 
> This is similar to what PCI bus does (if you look at pci_pm_init()).
> 
> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
> Author: Felipe Balbi <balbi@ti.com>
> Date:   Wed Jul 10 18:50:16 2013 +0300
> 
>     arm: omap2plus: unidle devices which are about to probe
>     
>     in order to make HWMOD and pm_runtime agree on the
>     initial state of the device, we will unidle the device
>     and call pm_runtime_set_active() to tell pm_runtime
>     that the device is really active.
>     
>     By the time driver's probe() is reached, a call to
>     pm_runtime_get_sync() will not cause driver's
>     ->runtime_resume() method to be called at first, only
>     after a successful ->runtime_suspend().
>     
>     Signed-off-by: Felipe Balbi <balbi@ti.com>

btw, this is RFC, haven't tested at all.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130710/18f596e3/attachment.sig>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 14:26                           ` Tony Lindgren
@ 2013-07-11  6:18                             ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-11  6:18 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Kevin Hilman, balbi, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> * Kevin Hilman <khilman@linaro.org> [130710 01:29]:
>> Felipe Balbi <balbi@ti.com> writes:
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>>
>>> Am I missing something ?
>>
>> You're right, the _set_active() is crucial in the case when we prevent
>> the console UART from idling during boot (though that shouldn't be
>> happening in mainline unless the fix for "Issue 1" is done.)
> 
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> 
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me.

On what platform? Like I said there are flags set statically in hmwod
data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
in mach-omap2/serial.c. But it won't work for am33xx.

 We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
> 
> Regards,
> 
> Tony
> 
> 
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
>  	u32			calc_latency;
>  	struct work_struct	qos_work;
>  	struct pinctrl		*pins;
> +	bool			initialized;
>  	bool			is_suspending;
>  };
>  
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>  
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
> +	up->initialized = true;

This won't help as the context save for serial happens as part of set_termios() and not
when the device is probed.

> +
>  	return 0;
>  
>  err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
>  #ifdef CONFIG_PM_RUNTIME
>  static void serial_omap_restore_context(struct uart_omap_port *up)
>  {
> +	if (!up->initialized)
> +		return;
> +
>  	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
>  		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
>  	else
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  6:18                             ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-11  6:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> * Kevin Hilman <khilman@linaro.org> [130710 01:29]:
>> Felipe Balbi <balbi@ti.com> writes:
>>>>
>>>> Right, but calling serial_omap_restore_context() even when the context
>>>> is not lost, should not ideally cause an issue.
>>>
>>> it does in one condition. If context hasn't been saved before. And that
>>> can happen in the case of wrong pm runtime status for that device.
>>>
>>> Imagine the device is marked as suspended even though it's fully enabled
>>> (it hasn't been suspended by hwmod due to NO_IDLE flag). In that case
>>> your context structure is all zeroes (context has never been saved
>>> before) then when you call pm_runtime_get_sync() on probe() your
>>> ->runtime_resume() will get called, which will restore context,
>>> essentially undoing anything which was configured by u-boot.
>>>
>>> Am I missing something ?
>>
>> You're right, the _set_active() is crucial in the case when we prevent
>> the console UART from idling during boot (though that shouldn't be
>> happening in mainline unless the fix for "Issue 1" is done.)
> 
> Felipe is right, looks like all we need is to check if context is
> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> 
> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> works for me.

On what platform? Like I said there are flags set statically in hmwod
data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
in mach-omap2/serial.c. But it won't work for am33xx.

 We could also check for some combination of the context
> save registers being NULL if somebody has a good idea which ones
> should never be 0.
> 
> Regards,
> 
> Tony
> 
> 
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -161,6 +161,7 @@ struct uart_omap_port {
>  	u32			calc_latency;
>  	struct work_struct	qos_work;
>  	struct pinctrl		*pins;
> +	bool			initialized;
>  	bool			is_suspending;
>  };
>  
> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>  
>  	pm_runtime_mark_last_busy(up->dev);
>  	pm_runtime_put_autosuspend(up->dev);
> +	up->initialized = true;

This won't help as the context save for serial happens as part of set_termios() and not
when the device is probed.

> +
>  	return 0;
>  
>  err_add_port:
> @@ -1584,6 +1587,9 @@ static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1)
>  #ifdef CONFIG_PM_RUNTIME
>  static void serial_omap_restore_context(struct uart_omap_port *up)
>  {
> +	if (!up->initialized)
> +		return;
> +
>  	if (up->errata & UART_ERRATA_i202_MDR1_ACCESS)
>  		serial_omap_mdr1_errataset(up, UART_OMAP_MDR1_DISABLE);
>  	else
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  6:18                             ` Rajendra Nayak
@ 2013-07-11  6:24                               ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-11  6:24 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Kevin Hilman, balbi, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

* Rajendra Nayak <rnayak@ti.com> [130710 23:25]:
> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> > 
> > Felipe is right, looks like all we need is to check if context is
> > initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> > 
> > After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> > works for me.
> 
> On what platform? Like I said there are flags set statically in hmwod
> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
> in mach-omap2/serial.c. But it won't work for am33xx.

For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
that port and console is enabled for that port. That's because we attempt
to restore uninitialized context.

It's possible that we have more than one bug here though.
 
> > @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
> >  
> >  	pm_runtime_mark_last_busy(up->dev);
> >  	pm_runtime_put_autosuspend(up->dev);
> > +	up->initialized = true;
> 
> This won't help as the context save for serial happens as part of set_termios() and not
> when the device is probed.

The issue is that in serial probe we currently restore NULL context to
the port which kills earlyprintk output until set_termios() is called.

But as discussed, there are better ways for fixing this issue.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  6:24                               ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-11  6:24 UTC (permalink / raw)
  To: linux-arm-kernel

* Rajendra Nayak <rnayak@ti.com> [130710 23:25]:
> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
> > 
> > Felipe is right, looks like all we need is to check if context is
> > initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
> > 
> > After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
> > works for me.
> 
> On what platform? Like I said there are flags set statically in hmwod
> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
> in mach-omap2/serial.c. But it won't work for am33xx.

For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
that port and console is enabled for that port. That's because we attempt
to restore uninitialized context.

It's possible that we have more than one bug here though.
 
> > @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
> >  
> >  	pm_runtime_mark_last_busy(up->dev);
> >  	pm_runtime_put_autosuspend(up->dev);
> > +	up->initialized = true;
> 
> This won't help as the context save for serial happens as part of set_termios() and not
> when the device is probed.

The issue is that in serial probe we currently restore NULL context to
the port which kills earlyprintk output until set_termios() is called.

But as discussed, there are better ways for fixing this issue.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 16:11                               ` Felipe Balbi
@ 2013-07-11  6:32                                 ` Tony Lindgren
  -1 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-11  6:32 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Kevin Hilman, Rajendra Nayak, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

* Felipe Balbi <balbi@ti.com> [130710 09:18]:
> 
> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
> > how about something like below ? It makes omap_device/hwmod and
> > pm_runtime agree on the initial state of the device and will prevent
> > ->runtime_resume() from being called on first pm_runtime_get*() done
> > during probe.
> > 
> > This is similar to what PCI bus does (if you look at pci_pm_init()).
> > 
> > commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
> > Author: Felipe Balbi <balbi@ti.com>
> > Date:   Wed Jul 10 18:50:16 2013 +0300
> > 
> >     arm: omap2plus: unidle devices which are about to probe
> >     
> >     in order to make HWMOD and pm_runtime agree on the
> >     initial state of the device, we will unidle the device
> >     and call pm_runtime_set_active() to tell pm_runtime
> >     that the device is really active.
> >     
> >     By the time driver's probe() is reached, a call to
> >     pm_runtime_get_sync() will not cause driver's
> >     ->runtime_resume() method to be called at first, only
> >     after a successful ->runtime_suspend().
> >     
> >     Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> btw, this is RFC, haven't tested at all.

Yes it does not compile, then removing the extra ; at the end
of the functions, it oopses with a NULL pointer exception.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  6:32                                 ` Tony Lindgren
  0 siblings, 0 replies; 96+ messages in thread
From: Tony Lindgren @ 2013-07-11  6:32 UTC (permalink / raw)
  To: linux-arm-kernel

* Felipe Balbi <balbi@ti.com> [130710 09:18]:
> 
> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
> > how about something like below ? It makes omap_device/hwmod and
> > pm_runtime agree on the initial state of the device and will prevent
> > ->runtime_resume() from being called on first pm_runtime_get*() done
> > during probe.
> > 
> > This is similar to what PCI bus does (if you look at pci_pm_init()).
> > 
> > commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
> > Author: Felipe Balbi <balbi@ti.com>
> > Date:   Wed Jul 10 18:50:16 2013 +0300
> > 
> >     arm: omap2plus: unidle devices which are about to probe
> >     
> >     in order to make HWMOD and pm_runtime agree on the
> >     initial state of the device, we will unidle the device
> >     and call pm_runtime_set_active() to tell pm_runtime
> >     that the device is really active.
> >     
> >     By the time driver's probe() is reached, a call to
> >     pm_runtime_get_sync() will not cause driver's
> >     ->runtime_resume() method to be called at first, only
> >     after a successful ->runtime_suspend().
> >     
> >     Signed-off-by: Felipe Balbi <balbi@ti.com>
> 
> btw, this is RFC, haven't tested at all.

Yes it does not compile, then removing the extra ; at the end
of the functions, it oopses with a NULL pointer exception.

Regards,

Tony

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  6:24                               ` Tony Lindgren
@ 2013-07-11  9:11                                 ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-11  9:11 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Kevin Hilman, balbi, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@ti.com> [130710 23:25]:
>> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
>>>
>>> Felipe is right, looks like all we need is to check if context is
>>> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
>>>
>>> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
>>> works for me.
>>
>> On what platform? Like I said there are flags set statically in hmwod
>> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
>> in mach-omap2/serial.c. But it won't work for am33xx.
> 
> For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
> that port and console is enabled for that port. That's because we attempt
> to restore uninitialized context.

Right, so thats the Issue 2: that you see on the omap4 sdp. You never hit
Issue 1: despite not doing any hwmod tinkering because of the static flags
set for uart3 in hwmod data.

> 
> It's possible that we have more than one bug here though.

Right, we have 2 issues like I said earlier. Issue 1: is when hwmod _setup()
does a console UART reset (Not seen if the flags are set either runtime or
statically)

Issue 2: Is when omap serial does a runtime resume before set_termios().

>  
>>> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>>>  
>>>  	pm_runtime_mark_last_busy(up->dev);
>>>  	pm_runtime_put_autosuspend(up->dev);
>>> +	up->initialized = true;
>>
>> This won't help as the context save for serial happens as part of set_termios() and not
>> when the device is probed.
> 
> The issue is that in serial probe we currently restore NULL context to
> the port which kills earlyprintk output until set_termios() is called.
> 
> But as discussed, there are better ways for fixing this issue.
> 
> Regards,
> 
> Tony
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  9:11                                 ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-11  9:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 11 July 2013 11:54 AM, Tony Lindgren wrote:
> * Rajendra Nayak <rnayak@ti.com> [130710 23:25]:
>> On Wednesday 10 July 2013 07:56 PM, Tony Lindgren wrote:
>>>
>>> Felipe is right, looks like all we need is to check if context is
>>> initialized or not. So no need for mach-omap2/serial.c or hwmod tinkering.
>>>
>>> After that having DEBUG_LL and cmdline with earlyprintk console=ttyO..
>>> works for me.
>>
>> On what platform? Like I said there are flags set statically in hmwod
>> data for OMAP4 and OMAP5, which make it work without any hwmod tinkering
>> in mach-omap2/serial.c. But it won't work for am33xx.
> 
> For me omap4 sdp hangs during ttyO2 probe if earlyprintk is enabled for
> that port and console is enabled for that port. That's because we attempt
> to restore uninitialized context.

Right, so thats the Issue 2: that you see on the omap4 sdp. You never hit
Issue 1: despite not doing any hwmod tinkering because of the static flags
set for uart3 in hwmod data.

> 
> It's possible that we have more than one bug here though.

Right, we have 2 issues like I said earlier. Issue 1: is when hwmod _setup()
does a console UART reset (Not seen if the flags are set either runtime or
statically)

Issue 2: Is when omap serial does a runtime resume before set_termios().

>  
>>> @@ -1523,6 +1524,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>>>  
>>>  	pm_runtime_mark_last_busy(up->dev);
>>>  	pm_runtime_put_autosuspend(up->dev);
>>> +	up->initialized = true;
>>
>> This won't help as the context save for serial happens as part of set_termios() and not
>> when the device is probed.
> 
> The issue is that in serial probe we currently restore NULL context to
> the port which kills earlyprintk output until set_termios() is called.
> 
> But as discussed, there are better ways for fixing this issue.
> 
> Regards,
> 
> Tony
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-10 16:07                             ` Felipe Balbi
@ 2013-07-11  9:17                               ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-11  9:17 UTC (permalink / raw)
  To: balbi
  Cc: Tony Lindgren, Kevin Hilman, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
> how about something like below ? It makes omap_device/hwmod and
> pm_runtime agree on the initial state of the device and will prevent
> ->runtime_resume() from being called on first pm_runtime_get*() done
> during probe.
> 
> This is similar to what PCI bus does (if you look at pci_pm_init()).

I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().

That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1

-----
static void update_autosuspend(struct device *dev, int old_delay, int old_use)
{
        int delay = dev->power.autosuspend_delay;

        /* Should runtime suspend be prevented now? */
        if (dev->power.use_autosuspend && delay < 0) {

                /* If it used to be allowed then prevent it. */
                if (!old_use || old_delay >= 0) {
                        atomic_inc(&dev->power.usage_count);
                        rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
                }
        }
-----

So we end up with the same issue with serial resume being called before set_termios()

[1]

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..c71d47d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
        struct device_node *node = pdev->dev.of_node;
        const char *oh_name;
        int oh_cnt, i, ret = 0;
+       bool device_active = false;
 
        oh_cnt = of_property_count_strings(node, "ti,hwmods");
        if (oh_cnt <= 0) {
@@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
                        goto odbfd_exit1;
                }
                hwmods[i] = oh;
+               if (oh->flags & HWMOD_INIT_NO_IDLE)
+                       device_active = true;
+                       
        }
 
        od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 
        pdev->dev.pm_domain = &omap_device_pm_domain;
 
+       if (device_active) {
+               omap_device_enable(pdev);
+               pm_runtime_set_active(&pdev->dev);
+       }
+       
 odbfd_exit1:
        kfree(hwmods);
 odbfd_exit:


^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  9:17                               ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-11  9:17 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
> how about something like below ? It makes omap_device/hwmod and
> pm_runtime agree on the initial state of the device and will prevent
> ->runtime_resume() from being called on first pm_runtime_get*() done
> during probe.
> 
> This is similar to what PCI bus does (if you look at pci_pm_init()).

I tried something similar [1] but what I found is that the serial
runtime resume was called despite it being marked as active using
pm_runtime_set_active().

That seems to be because of the pm_runtime_set_autosuspend_delay()
because we have the autosuspend_delay = -1

-----
static void update_autosuspend(struct device *dev, int old_delay, int old_use)
{
        int delay = dev->power.autosuspend_delay;

        /* Should runtime suspend be prevented now? */
        if (dev->power.use_autosuspend && delay < 0) {

                /* If it used to be allowed then prevent it. */
                if (!old_use || old_delay >= 0) {
                        atomic_inc(&dev->power.usage_count);
                        rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
                }
        }
-----

So we end up with the same issue with serial resume being called before set_termios()

[1]

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..c71d47d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
        struct device_node *node = pdev->dev.of_node;
        const char *oh_name;
        int oh_cnt, i, ret = 0;
+       bool device_active = false;
 
        oh_cnt = of_property_count_strings(node, "ti,hwmods");
        if (oh_cnt <= 0) {
@@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
                        goto odbfd_exit1;
                }
                hwmods[i] = oh;
+               if (oh->flags & HWMOD_INIT_NO_IDLE)
+                       device_active = true;
+                       
        }
 
        od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 
        pdev->dev.pm_domain = &omap_device_pm_domain;
 
+       if (device_active) {
+               omap_device_enable(pdev);
+               pm_runtime_set_active(&pdev->dev);
+       }
+       
 odbfd_exit1:
        kfree(hwmods);
 odbfd_exit:

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  9:17                               ` Rajendra Nayak
@ 2013-07-11  9:26                                 ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-11  9:26 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: balbi, Tony Lindgren, Kevin Hilman, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]

Hi,

On Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
> > how about something like below ? It makes omap_device/hwmod and
> > pm_runtime agree on the initial state of the device and will prevent
> > ->runtime_resume() from being called on first pm_runtime_get*() done
> > during probe.
> > 
> > This is similar to what PCI bus does (if you look at pci_pm_init()).
> 
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
> 
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
> 
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>         int delay = dev->power.autosuspend_delay;
> 
>         /* Should runtime suspend be prevented now? */
>         if (dev->power.use_autosuspend && delay < 0) {
> 
>                 /* If it used to be allowed then prevent it. */
>                 if (!old_use || old_delay >= 0) {
>                         atomic_inc(&dev->power.usage_count);
>                         rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>                 }
>         }
> -----
> 
> So we end up with the same issue with serial resume being called before set_termios()

yeah, that part I figured out after I started testing today. It seems
like my latest version is getting closer but I still see problems, diff
below:

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index e6d2307..0cc2da9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+	omap_device_enable(pdev);
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+	pm_runtime_allow(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -192,16 +212,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_allow(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-		/* fall through */
+		break;
 	default:
-		od = to_omap_device(pdev);
-		if (od)
-			od->_driver_status = event;
+		/* nothing */
+		break;
 	}
 
+	od = to_omap_device(pdev);
+	if (od)
+		od->_driver_status = event;
+
 	return NOTIFY_DONE;
 }
 

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  9:26                                 ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-11  9:26 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Thu, Jul 11, 2013 at 02:47:00PM +0530, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
> > how about something like below ? It makes omap_device/hwmod and
> > pm_runtime agree on the initial state of the device and will prevent
> > ->runtime_resume() from being called on first pm_runtime_get*() done
> > during probe.
> > 
> > This is similar to what PCI bus does (if you look at pci_pm_init()).
> 
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
> 
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
> 
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>         int delay = dev->power.autosuspend_delay;
> 
>         /* Should runtime suspend be prevented now? */
>         if (dev->power.use_autosuspend && delay < 0) {
> 
>                 /* If it used to be allowed then prevent it. */
>                 if (!old_use || old_delay >= 0) {
>                         atomic_inc(&dev->power.usage_count);
>                         rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>                 }
>         }
> -----
> 
> So we end up with the same issue with serial resume being called before set_termios()

yeah, that part I figured out after I started testing today. It seems
like my latest version is getting closer but I still see problems, diff
below:

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index e6d2307..0cc2da9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -181,6 +181,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+	omap_device_enable(pdev);
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+	pm_runtime_allow(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -192,16 +212,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_allow(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-		/* fall through */
+		break;
 	default:
-		od = to_omap_device(pdev);
-		if (od)
-			od->_driver_status = event;
+		/* nothing */
+		break;
 	}
 
+	od = to_omap_device(pdev);
+	if (od)
+		od->_driver_status = event;
+
 	return NOTIFY_DONE;
 }
 

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130711/01d3f194/attachment.sig>

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  9:17                               ` Rajendra Nayak
@ 2013-07-11  9:59                                 ` Grygorii Strashko
  -1 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-11  9:59 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: balbi, Tony Lindgren, Kevin Hilman, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
>
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
>
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>          int delay = dev->power.autosuspend_delay;
>
>          /* Should runtime suspend be prevented now? */
>          if (dev->power.use_autosuspend && delay < 0) {
>
>                  /* If it used to be allowed then prevent it. */
>                  if (!old_use || old_delay >= 0) {
>                          atomic_inc(&dev->power.usage_count);
>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
It's strange - the check for status is inside rpm_resume()

if (dev->power.runtime_status == RPM_ACTIVE) {
		retval = 1;
		goto out;
	}

So, if status is set to RPM_ACTIVE before first call to:
  pm_runtime_use_autosuspend(&pdev->dev);
  pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
-- or --
  pm_runtime_get*()
everything should be ok.

May be the problem is inside serial_omap_set_termios() where 
pm_runtime_get_sync is called before context is initialized.
probe:
  get - status is ACTIVE and serial resume is not called
  put - status is IDLE

set_termios
  get - status is IDLE and serial resume is called


>                  }
>          }
> -----
>
> So we end up with the same issue with serial resume being called before set_termios()
>
> [1]
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..c71d47d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>          struct device_node *node = pdev->dev.of_node;
>          const char *oh_name;
>          int oh_cnt, i, ret = 0;
> +       bool device_active = false;
>
>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>          if (oh_cnt <= 0) {
> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>                          goto odbfd_exit1;
>                  }
>                  hwmods[i] = oh;
> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
> +                       device_active = true;
> +
>          }
>
>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>
>          pdev->dev.pm_domain = &omap_device_pm_domain;
>
> +       if (device_active) {
> +               omap_device_enable(pdev);
> +               pm_runtime_set_active(&pdev->dev);
> +       }
> +
>   odbfd_exit1:
>          kfree(hwmods);
>   odbfd_exit:
>
> --
> 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] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  9:59                                 ` Grygorii Strashko
  0 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-11  9:59 UTC (permalink / raw)
  To: linux-arm-kernel

On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
>
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
>
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>          int delay = dev->power.autosuspend_delay;
>
>          /* Should runtime suspend be prevented now? */
>          if (dev->power.use_autosuspend && delay < 0) {
>
>                  /* If it used to be allowed then prevent it. */
>                  if (!old_use || old_delay >= 0) {
>                          atomic_inc(&dev->power.usage_count);
>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
It's strange - the check for status is inside rpm_resume()

if (dev->power.runtime_status == RPM_ACTIVE) {
		retval = 1;
		goto out;
	}

So, if status is set to RPM_ACTIVE before first call to:
  pm_runtime_use_autosuspend(&pdev->dev);
  pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
-- or --
  pm_runtime_get*()
everything should be ok.

May be the problem is inside serial_omap_set_termios() where 
pm_runtime_get_sync is called before context is initialized.
probe:
  get - status is ACTIVE and serial resume is not called
  put - status is IDLE

set_termios
  get - status is IDLE and serial resume is called


>                  }
>          }
> -----
>
> So we end up with the same issue with serial resume being called before set_termios()
>
> [1]
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..c71d47d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>          struct device_node *node = pdev->dev.of_node;
>          const char *oh_name;
>          int oh_cnt, i, ret = 0;
> +       bool device_active = false;
>
>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>          if (oh_cnt <= 0) {
> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>                          goto odbfd_exit1;
>                  }
>                  hwmods[i] = oh;
> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
> +                       device_active = true;
> +
>          }
>
>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>
>          pdev->dev.pm_domain = &omap_device_pm_domain;
>
> +       if (device_active) {
> +               omap_device_enable(pdev);
> +               pm_runtime_set_active(&pdev->dev);
> +       }
> +
>   odbfd_exit1:
>          kfree(hwmods);
>   odbfd_exit:
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  6:32                                 ` Tony Lindgren
@ 2013-07-11  9:59                                   ` Grygorii Strashko
  -1 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-11  9:59 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Felipe Balbi, Kevin Hilman, Rajendra Nayak, Bedia, Vaibhav,
	linux-omap, linux-arm-kernel, Mark Jackson, Sourav Poddar,
	Paul Walmsley, Anna, Suman

Hi,

On 07/11/2013 09:32 AM, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>
>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>> how about something like below ? It makes omap_device/hwmod and
>>> pm_runtime agree on the initial state of the device and will prevent
>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>> during probe.
>>>
>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>
>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>> Author: Felipe Balbi <balbi@ti.com>
>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>
>>>      arm: omap2plus: unidle devices which are about to probe
>>>
>>>      in order to make HWMOD and pm_runtime agree on the
>>>      initial state of the device, we will unidle the device
>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>      that the device is really active.
Don't think that it's good idea (
I've checked some driver's and think this patch will enable some devices 
unpredictably:
- hwspinlock
- mailbox
- iommu
- ipu
All above devices need to be enabled on demand only (no 
pm_runtime_get*() calls in probe). More over, some of them have very 
specific enabling sequence - like ipu).

May be Summan can say more on that.

>>>
>>>      By the time driver's probe() is reached, a call to
>>>      pm_runtime_get_sync() will not cause driver's
>>>      ->runtime_resume() method to be called at first, only
>>>      after a successful ->runtime_suspend().
>>>
>>>      Signed-off-by: Felipe Balbi <balbi@ti.com>
>>
>> btw, this is RFC, haven't tested at all.
>
> Yes it does not compile, then removing the extra ; at the end
> of the functions, it oopses with a NULL pointer exception.
>
> Regards,
>
> Tony
> --
> 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] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-11  9:59                                   ` Grygorii Strashko
  0 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-11  9:59 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On 07/11/2013 09:32 AM, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>
>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>> how about something like below ? It makes omap_device/hwmod and
>>> pm_runtime agree on the initial state of the device and will prevent
>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>> during probe.
>>>
>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>
>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>> Author: Felipe Balbi <balbi@ti.com>
>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>
>>>      arm: omap2plus: unidle devices which are about to probe
>>>
>>>      in order to make HWMOD and pm_runtime agree on the
>>>      initial state of the device, we will unidle the device
>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>      that the device is really active.
Don't think that it's good idea (
I've checked some driver's and think this patch will enable some devices 
unpredictably:
- hwspinlock
- mailbox
- iommu
- ipu
All above devices need to be enabled on demand only (no 
pm_runtime_get*() calls in probe). More over, some of them have very 
specific enabling sequence - like ipu).

May be Summan can say more on that.

>>>
>>>      By the time driver's probe() is reached, a call to
>>>      pm_runtime_get_sync() will not cause driver's
>>>      ->runtime_resume() method to be called at first, only
>>>      after a successful ->runtime_suspend().
>>>
>>>      Signed-off-by: Felipe Balbi <balbi@ti.com>
>>
>> btw, this is RFC, haven't tested at all.
>
> Yes it does not compile, then removing the extra ; at the end
> of the functions, it oopses with a NULL pointer exception.
>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* [PATCH] arm: omap2plus: unidle devices which are about to probe
  2013-07-11  9:26                                 ` Felipe Balbi
@ 2013-07-11 10:16                                   ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-11 10:16 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Rajendra Nayak, Kevin Hilman, Linux OMAP Mailing List,
	vaibhav.bedia, linux-arm-kernel, mpfj-list, Sourav Poddar, paul,
	Felipe Balbi

in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.

By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
->runtime_resume() method to be called at first, only
after a successful ->runtime_suspend().

Note that we must prevent pm_runtime transitions while
driver is probing otherwise drivers would be suspended
as soon as they call pm_runtime_use_autosuspend(). By
calling pm_runtime_forbid() before probe() and
pm_runtime_allow() after probe() we 'fix' that detail.

Note that this patch was inspired by PCI's pci_pm_init().

Signed-off-by: Felipe Balbi <balbi@ti.com>
---

boot tested on top of today's Linus master
6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
panda. Reached console prompt and, after setting a
proper autosuspend delay, consoles autosuspend just
fine.

It needs to be tested on other platforms.

ps: note that we also call pm_runtime_set_suspended(dev)
from our late_initcall() to disable devices so that pm_runtime
and HWMOD continue to aggree on device's state.

 arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..cb1fc1d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+	omap_device_enable(pdev);
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+	pm_runtime_allow(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_allow(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-		/* fall through */
+		break;
 	default:
-		od = to_omap_device(pdev);
-		if (od)
-			od->_driver_status = event;
+		/* nothing */
+		break;
 	}
 
+	od = to_omap_device(pdev);
+	if (od)
+		od->_driver_status = event;
+
 	return NOTIFY_DONE;
 }
 
@@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
 				 __func__);
 			omap_device_idle(pdev);
+			pm_runtime_set_suspended(dev);
 		}
 	}
 
-- 
1.8.2.1


^ permalink raw reply related	[flat|nested] 96+ messages in thread

* [PATCH] arm: omap2plus: unidle devices which are about to probe
@ 2013-07-11 10:16                                   ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-11 10:16 UTC (permalink / raw)
  To: linux-arm-kernel

in order to make HWMOD and pm_runtime agree on the
initial state of the device, we will unidle the device
and call pm_runtime_set_active() to tell pm_runtime
that the device is really active.

By the time driver's probe() is reached, a call to
pm_runtime_get_sync() will not cause driver's
->runtime_resume() method to be called at first, only
after a successful ->runtime_suspend().

Note that we must prevent pm_runtime transitions while
driver is probing otherwise drivers would be suspended
as soon as they call pm_runtime_use_autosuspend(). By
calling pm_runtime_forbid() before probe() and
pm_runtime_allow() after probe() we 'fix' that detail.

Note that this patch was inspired by PCI's pci_pm_init().

Signed-off-by: Felipe Balbi <balbi@ti.com>
---

boot tested on top of today's Linus master
6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
panda. Reached console prompt and, after setting a
proper autosuspend delay, consoles autosuspend just
fine.

It needs to be tested on other platforms.

ps: note that we also call pm_runtime_set_suspended(dev)
from our late_initcall() to disable devices so that pm_runtime
and HWMOD continue to aggree on device's state.

 arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..cb1fc1d 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,26 @@ odbfd_exit:
 	return ret;
 }
 
+static void omap_device_pm_init(struct platform_device *pdev)
+{
+	omap_device_enable(pdev);
+	pm_runtime_forbid(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	device_enable_async_suspend(&pdev->dev);
+}
+
+static void omap_device_pm_allow(struct platform_device *pdev)
+{
+	pm_runtime_allow(&pdev->dev);
+}
+
+static void omap_device_pm_exit(struct platform_device *pdev)
+{
+	device_disable_async_suspend(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	omap_device_idle(pdev);
+}
+
 static int _omap_device_notifier_call(struct notifier_block *nb,
 				      unsigned long event, void *dev)
 {
@@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_BIND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_init(pdev);
+		break;
+	case BUS_NOTIFY_BOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_allow(pdev);
+		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		if (pdev->archdata.od)
+			omap_device_pm_exit(pdev);
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-		/* fall through */
+		break;
 	default:
-		od = to_omap_device(pdev);
-		if (od)
-			od->_driver_status = event;
+		/* nothing */
+		break;
 	}
 
+	od = to_omap_device(pdev);
+	if (od)
+		od->_driver_status = event;
+
 	return NOTIFY_DONE;
 }
 
@@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
 				 __func__);
 			omap_device_idle(pdev);
+			pm_runtime_set_suspended(dev);
 		}
 	}
 
-- 
1.8.2.1

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  9:59                                   ` Grygorii Strashko
@ 2013-07-12  0:40                                     ` Suman Anna
  -1 siblings, 0 replies; 96+ messages in thread
From: Suman Anna @ 2013-07-12  0:40 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Tony Lindgren, Felipe Balbi, Kevin Hilman, Rajendra Nayak, Bedia,
	Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar, Paul Walmsley

On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
> Hi,
> 
> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>
>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>> how about something like below ? It makes omap_device/hwmod and
>>>> pm_runtime agree on the initial state of the device and will prevent
>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>> during probe.
>>>>
>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>
>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>> Author: Felipe Balbi <balbi@ti.com>
>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>
>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>
>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>      initial state of the device, we will unidle the device
>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>      that the device is really active.
> Don't think that it's good idea (
> I've checked some driver's and think this patch will enable some devices
> unpredictably:
> - hwspinlock
> - mailbox
> - iommu
> - ipu
> All above devices need to be enabled on demand only (no
> pm_runtime_get*() calls in probe). More over, some of them have very
> specific enabling sequence - like ipu).
> 
> May be Summan can say more on that.

Indeed, this is a problem for any of the slave processor devices.
mailbox and iommu would be slaves to the remoteproc and the drivers have
a specific sequence of bringing up a processor. The current
hwmod/omap_device code is such that these devices will be left in reset
and the driver code use the omap_device_(de)assert_hardreset API
together with omap_device_enable code to bring up the devices. The
remoteproc driver also needs to assert the resets (there are other
problems associated with using omap_device_idle for remoteproc and
iommu) for bringing up the devices after a suspend sequence. hwspinlock
and mailbox may get away since they are in CORE domain, but definitely
an issue for iommu and remoteproc. I would think that this would also
affect other compute devices like IVAHD, ISS, SGX.

regards
Suman

> 
>>>>
>>>>      By the time driver's probe() is reached, a call to
>>>>      pm_runtime_get_sync() will not cause driver's
>>>>      ->runtime_resume() method to be called at first, only
>>>>      after a successful ->runtime_suspend().
>>>>
>>>>      Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>
>>> btw, this is RFC, haven't tested at all.
>>
>> Yes it does not compile, then removing the extra ; at the end
>> of the functions, it oopses with a NULL pointer exception.
>>
>> Regards,
>>
>> Tony
>> -- 
>> 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] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-12  0:40                                     ` Suman Anna
  0 siblings, 0 replies; 96+ messages in thread
From: Suman Anna @ 2013-07-12  0:40 UTC (permalink / raw)
  To: linux-arm-kernel

On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
> Hi,
> 
> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>
>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>> how about something like below ? It makes omap_device/hwmod and
>>>> pm_runtime agree on the initial state of the device and will prevent
>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>> during probe.
>>>>
>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>
>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>> Author: Felipe Balbi <balbi@ti.com>
>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>
>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>
>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>      initial state of the device, we will unidle the device
>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>      that the device is really active.
> Don't think that it's good idea (
> I've checked some driver's and think this patch will enable some devices
> unpredictably:
> - hwspinlock
> - mailbox
> - iommu
> - ipu
> All above devices need to be enabled on demand only (no
> pm_runtime_get*() calls in probe). More over, some of them have very
> specific enabling sequence - like ipu).
> 
> May be Summan can say more on that.

Indeed, this is a problem for any of the slave processor devices.
mailbox and iommu would be slaves to the remoteproc and the drivers have
a specific sequence of bringing up a processor. The current
hwmod/omap_device code is such that these devices will be left in reset
and the driver code use the omap_device_(de)assert_hardreset API
together with omap_device_enable code to bring up the devices. The
remoteproc driver also needs to assert the resets (there are other
problems associated with using omap_device_idle for remoteproc and
iommu) for bringing up the devices after a suspend sequence. hwspinlock
and mailbox may get away since they are in CORE domain, but definitely
an issue for iommu and remoteproc. I would think that this would also
affect other compute devices like IVAHD, ISS, SGX.

regards
Suman

> 
>>>>
>>>>      By the time driver's probe() is reached, a call to
>>>>      pm_runtime_get_sync() will not cause driver's
>>>>      ->runtime_resume() method to be called at first, only
>>>>      after a successful ->runtime_suspend().
>>>>
>>>>      Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>
>>> btw, this is RFC, haven't tested at all.
>>
>> Yes it does not compile, then removing the extra ; at the end
>> of the functions, it oopses with a NULL pointer exception.
>>
>> Regards,
>>
>> Tony
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
  2013-07-11 10:16                                   ` Felipe Balbi
@ 2013-07-12 11:58                                     ` Grygorii Strashko
  -1 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-12 11:58 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Tony Lindgren, Rajendra Nayak, Kevin Hilman,
	Linux OMAP Mailing List, vaibhav.bedia, linux-arm-kernel,
	mpfj-list, Sourav Poddar, paul

On 07/11/2013 01:16 PM, Felipe Balbi wrote:
> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.
>
> Note that this patch was inspired by PCI's pci_pm_init().

NAK. This is a hack.
In addition to what I've mentioned in
http://www.spinics.net/lists/arm-kernel/msg258061.html there are 
following issues:
1) this patch disables call to PM runtime callbacks for all
OMAP drivers which is wrong - I've found, for example, that
omap-usb-host.c driver enables TLL in some configurations in its
.runtime_resume():

usbhs_runtime_resume()
|-omap_tll_enable()


2) even with this fix the restore context issue will not be fixed for 
*non* console UARTs. Just try:
#echo 0xDEAD > dev/ttyO3 // checked on OMAP4 SDP

3) I've checked most of OMAP drivers and all of them solve such kind of 
problem internally (SPI, MMC, I2C, etc.)

4) See inline
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.
>
>   arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
>   1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
>   	return ret;
>   }
>
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> +	omap_device_enable(pdev);
> +	pm_runtime_forbid(&pdev->dev);
It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume() should 
be used instead.
pm_runtime_forbid()
|-rpm_resume()


> +	pm_runtime_set_active(&pdev->dev);
> +	device_enable_async_suspend(&pdev->dev);
why did you use device_enable_async_suspend() - it would enable async 
suspend for devices - this is not related to the current issue and topic 
for discussion (currently is used by usb/scsi/pci/ata drivers only).
> +}
> +
> +static void omap_device_pm_allow(struct platform_device *pdev)
> +{
> +	pm_runtime_allow(&pdev->dev);
> +}
> +
> +static void omap_device_pm_exit(struct platform_device *pdev)
> +{
> +	device_disable_async_suspend(&pdev->dev);
> +	pm_runtime_set_suspended(&pdev->dev);
> +	omap_device_idle(pdev);
> +}
> +
>   static int _omap_device_notifier_call(struct notifier_block *nb,
>   				      unsigned long event, void *dev)
>   {
> @@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>   		if (pdev->archdata.od)
>   			omap_device_delete(pdev->archdata.od);
>   		break;
> +	case BUS_NOTIFY_BIND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_init(pdev);
> +		break;
> +	case BUS_NOTIFY_BOUND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_allow(pdev);
> +		break;
> +	case BUS_NOTIFY_UNBOUND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_exit(pdev);
> +		break;
>   	case BUS_NOTIFY_ADD_DEVICE:
>   		if (pdev->dev.of_node)
>   			omap_device_build_from_dt(pdev);
> -		/* fall through */
> +		break;
>   	default:
> -		od = to_omap_device(pdev);
> -		if (od)
> -			od->_driver_status = event;
> +		/* nothing */
> +		break;
>   	}
>
> +	od = to_omap_device(pdev);
> +	if (od)
> +		od->_driver_status = event;
> +
>   	return NOTIFY_DONE;
>   }
>
> @@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
>   			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
>   				 __func__);
>   			omap_device_idle(pdev);
> +			pm_runtime_set_suspended(dev);
>   		}
>   	}
>
>


^ permalink raw reply	[flat|nested] 96+ messages in thread

* [PATCH] arm: omap2plus: unidle devices which are about to probe
@ 2013-07-12 11:58                                     ` Grygorii Strashko
  0 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-12 11:58 UTC (permalink / raw)
  To: linux-arm-kernel

On 07/11/2013 01:16 PM, Felipe Balbi wrote:
> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.
>
> Note that this patch was inspired by PCI's pci_pm_init().

NAK. This is a hack.
In addition to what I've mentioned in
http://www.spinics.net/lists/arm-kernel/msg258061.html there are 
following issues:
1) this patch disables call to PM runtime callbacks for all
OMAP drivers which is wrong - I've found, for example, that
omap-usb-host.c driver enables TLL in some configurations in its
.runtime_resume():

usbhs_runtime_resume()
|-omap_tll_enable()


2) even with this fix the restore context issue will not be fixed for 
*non* console UARTs. Just try:
#echo 0xDEAD > dev/ttyO3 // checked on OMAP4 SDP

3) I've checked most of OMAP drivers and all of them solve such kind of 
problem internally (SPI, MMC, I2C, etc.)

4) See inline
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.
>
>   arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
>   1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
>   	return ret;
>   }
>
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> +	omap_device_enable(pdev);
> +	pm_runtime_forbid(&pdev->dev);
It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume() should 
be used instead.
pm_runtime_forbid()
|-rpm_resume()


> +	pm_runtime_set_active(&pdev->dev);
> +	device_enable_async_suspend(&pdev->dev);
why did you use device_enable_async_suspend() - it would enable async 
suspend for devices - this is not related to the current issue and topic 
for discussion (currently is used by usb/scsi/pci/ata drivers only).
> +}
> +
> +static void omap_device_pm_allow(struct platform_device *pdev)
> +{
> +	pm_runtime_allow(&pdev->dev);
> +}
> +
> +static void omap_device_pm_exit(struct platform_device *pdev)
> +{
> +	device_disable_async_suspend(&pdev->dev);
> +	pm_runtime_set_suspended(&pdev->dev);
> +	omap_device_idle(pdev);
> +}
> +
>   static int _omap_device_notifier_call(struct notifier_block *nb,
>   				      unsigned long event, void *dev)
>   {
> @@ -189,16 +209,31 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>   		if (pdev->archdata.od)
>   			omap_device_delete(pdev->archdata.od);
>   		break;
> +	case BUS_NOTIFY_BIND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_init(pdev);
> +		break;
> +	case BUS_NOTIFY_BOUND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_allow(pdev);
> +		break;
> +	case BUS_NOTIFY_UNBOUND_DRIVER:
> +		if (pdev->archdata.od)
> +			omap_device_pm_exit(pdev);
> +		break;
>   	case BUS_NOTIFY_ADD_DEVICE:
>   		if (pdev->dev.of_node)
>   			omap_device_build_from_dt(pdev);
> -		/* fall through */
> +		break;
>   	default:
> -		od = to_omap_device(pdev);
> -		if (od)
> -			od->_driver_status = event;
> +		/* nothing */
> +		break;
>   	}
>
> +	od = to_omap_device(pdev);
> +	if (od)
> +		od->_driver_status = event;
> +
>   	return NOTIFY_DONE;
>   }
>
> @@ -855,6 +890,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
>   			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
>   				 __func__);
>   			omap_device_idle(pdev);
> +			pm_runtime_set_suspended(dev);
>   		}
>   	}
>
>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
  2013-07-12 11:58                                     ` Grygorii Strashko
@ 2013-07-12 12:10                                       ` Felipe Balbi
  -1 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-12 12:10 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: Felipe Balbi, Tony Lindgren, Rajendra Nayak, Kevin Hilman,
	Linux OMAP Mailing List, vaibhav.bedia, linux-arm-kernel,
	mpfj-list, Sourav Poddar, paul

[-- Attachment #1: Type: text/plain, Size: 3390 bytes --]

On Fri, Jul 12, 2013 at 02:58:17PM +0300, Grygorii Strashko wrote:
> On 07/11/2013 01:16 PM, Felipe Balbi wrote:
> >in order to make HWMOD and pm_runtime agree on the
> >initial state of the device, we will unidle the device
> >and call pm_runtime_set_active() to tell pm_runtime
> >that the device is really active.
> >
> >By the time driver's probe() is reached, a call to
> >pm_runtime_get_sync() will not cause driver's
> >->runtime_resume() method to be called at first, only
> >after a successful ->runtime_suspend().
> >
> >Note that we must prevent pm_runtime transitions while
> >driver is probing otherwise drivers would be suspended
> >as soon as they call pm_runtime_use_autosuspend(). By
> >calling pm_runtime_forbid() before probe() and
> >pm_runtime_allow() after probe() we 'fix' that detail.
> >
> >Note that this patch was inspired by PCI's pci_pm_init().
> 
> NAK. This is a hack.

hack is your flag to check if the driver is "initialized". pff

> In addition to what I've mentioned in
> http://www.spinics.net/lists/arm-kernel/msg258061.html there are
> following issues:
> 1) this patch disables call to PM runtime callbacks for all

no, it does not. It forbids pm runtime transitions during probe.

> OMAP drivers which is wrong - I've found, for example, that
> omap-usb-host.c driver enables TLL in some configurations in its
> .runtime_resume():
> 
> usbhs_runtime_resume()
> |-omap_tll_enable()

which is wrong. PM runtime callbacks are supposed to be use for,
surprise, PM!

> 2) even with this fix the restore context issue will not be fixed for
> *non* console UARTs. Just try:
> #echo 0xDEAD > dev/ttyO3 // checked on OMAP4 SDP

that I have not checked, but then again, with that you're not calling
set_termios() anyway.

> 3) I've checked most of OMAP drivers and all of them solve such kind
> of problem internally (SPI, MMC, I2C, etc.)

and you see no problem with that ? Repeating the same thing over and
over again ?

> 4) See inline
> >
> >Signed-off-by: Felipe Balbi <balbi@ti.com>
> >---
> >
> >boot tested on top of today's Linus master
> >6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> >panda. Reached console prompt and, after setting a
> >proper autosuspend delay, consoles autosuspend just
> >fine.
> >
> >It needs to be tested on other platforms.
> >
> >ps: note that we also call pm_runtime_set_suspended(dev)
> >from our late_initcall() to disable devices so that pm_runtime
> >and HWMOD continue to aggree on device's state.
> >
> >  arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
> >  1 file changed, 40 insertions(+), 4 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> >index 5cc9287..cb1fc1d 100644
> >--- a/arch/arm/mach-omap2/omap_device.c
> >+++ b/arch/arm/mach-omap2/omap_device.c
> >@@ -178,6 +178,26 @@ odbfd_exit:
> >  	return ret;
> >  }
> >
> >+static void omap_device_pm_init(struct platform_device *pdev)
> >+{
> >+	omap_device_enable(pdev);
> >+	pm_runtime_forbid(&pdev->dev);
> It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume()
> should be used instead.

how come ? What makes you think pm_runtime_get_noresume() is the right
thing here ? 

> pm_runtime_forbid()
> |-rpm_resume()

so what ? flags is zero.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 96+ messages in thread

* [PATCH] arm: omap2plus: unidle devices which are about to probe
@ 2013-07-12 12:10                                       ` Felipe Balbi
  0 siblings, 0 replies; 96+ messages in thread
From: Felipe Balbi @ 2013-07-12 12:10 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jul 12, 2013 at 02:58:17PM +0300, Grygorii Strashko wrote:
> On 07/11/2013 01:16 PM, Felipe Balbi wrote:
> >in order to make HWMOD and pm_runtime agree on the
> >initial state of the device, we will unidle the device
> >and call pm_runtime_set_active() to tell pm_runtime
> >that the device is really active.
> >
> >By the time driver's probe() is reached, a call to
> >pm_runtime_get_sync() will not cause driver's
> >->runtime_resume() method to be called at first, only
> >after a successful ->runtime_suspend().
> >
> >Note that we must prevent pm_runtime transitions while
> >driver is probing otherwise drivers would be suspended
> >as soon as they call pm_runtime_use_autosuspend(). By
> >calling pm_runtime_forbid() before probe() and
> >pm_runtime_allow() after probe() we 'fix' that detail.
> >
> >Note that this patch was inspired by PCI's pci_pm_init().
> 
> NAK. This is a hack.

hack is your flag to check if the driver is "initialized". pff

> In addition to what I've mentioned in
> http://www.spinics.net/lists/arm-kernel/msg258061.html there are
> following issues:
> 1) this patch disables call to PM runtime callbacks for all

no, it does not. It forbids pm runtime transitions during probe.

> OMAP drivers which is wrong - I've found, for example, that
> omap-usb-host.c driver enables TLL in some configurations in its
> .runtime_resume():
> 
> usbhs_runtime_resume()
> |-omap_tll_enable()

which is wrong. PM runtime callbacks are supposed to be use for,
surprise, PM!

> 2) even with this fix the restore context issue will not be fixed for
> *non* console UARTs. Just try:
> #echo 0xDEAD > dev/ttyO3 // checked on OMAP4 SDP

that I have not checked, but then again, with that you're not calling
set_termios() anyway.

> 3) I've checked most of OMAP drivers and all of them solve such kind
> of problem internally (SPI, MMC, I2C, etc.)

and you see no problem with that ? Repeating the same thing over and
over again ?

> 4) See inline
> >
> >Signed-off-by: Felipe Balbi <balbi@ti.com>
> >---
> >
> >boot tested on top of today's Linus master
> >6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> >panda. Reached console prompt and, after setting a
> >proper autosuspend delay, consoles autosuspend just
> >fine.
> >
> >It needs to be tested on other platforms.
> >
> >ps: note that we also call pm_runtime_set_suspended(dev)
> >from our late_initcall() to disable devices so that pm_runtime
> >and HWMOD continue to aggree on device's state.
> >
> >  arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
> >  1 file changed, 40 insertions(+), 4 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> >index 5cc9287..cb1fc1d 100644
> >--- a/arch/arm/mach-omap2/omap_device.c
> >+++ b/arch/arm/mach-omap2/omap_device.c
> >@@ -178,6 +178,26 @@ odbfd_exit:
> >  	return ret;
> >  }
> >
> >+static void omap_device_pm_init(struct platform_device *pdev)
> >+{
> >+	omap_device_enable(pdev);
> >+	pm_runtime_forbid(&pdev->dev);
> It's wrong to use pm_runtime_forbid() - pm_runtime_get_noresume()
> should be used instead.

how come ? What makes you think pm_runtime_get_noresume() is the right
thing here ? 

> pm_runtime_forbid()
> |-rpm_resume()

so what ? flags is zero.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130712/316a3665/attachment.sig>

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
  2013-07-12 12:10                                       ` Felipe Balbi
@ 2013-07-12 12:27                                         ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-12 12:27 UTC (permalink / raw)
  To: balbi
  Cc: paul, Grygorii Strashko, mpfj-list, Tony Lindgren, vaibhav.bedia,
	Kevin Hilman, Sourav Poddar, Linux OMAP Mailing List,
	linux-arm-kernel

On Friday 12 July 2013 05:40 PM, Felipe Balbi wrote:
>> 3) I've checked most of OMAP drivers and all of them solve such kind
>> > of problem internally (SPI, MMC, I2C, etc.)
> and you see no problem with that ? Repeating the same thing over and
> over again ?
> 

I agree with Felipe that this is best handled at the bus/omap-device level
to avoid all drivers having to repeat the same thing over.
Having said that I dont know whats the best way to do this for OMAP and the
patch we have currently does seem to have atleast issues handling processor
IPs as Suman mentioned.

regards,
Rajendra

^ permalink raw reply	[flat|nested] 96+ messages in thread

* [PATCH] arm: omap2plus: unidle devices which are about to probe
@ 2013-07-12 12:27                                         ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-12 12:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 12 July 2013 05:40 PM, Felipe Balbi wrote:
>> 3) I've checked most of OMAP drivers and all of them solve such kind
>> > of problem internally (SPI, MMC, I2C, etc.)
> and you see no problem with that ? Repeating the same thing over and
> over again ?
> 

I agree with Felipe that this is best handled at the bus/omap-device level
to avoid all drivers having to repeat the same thing over.
Having said that I dont know whats the best way to do this for OMAP and the
patch we have currently does seem to have atleast issues handling processor
IPs as Suman mentioned.

regards,
Rajendra

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
  2013-07-11 10:16                                   ` Felipe Balbi
@ 2013-07-13 22:21                                     ` Kevin Hilman
  -1 siblings, 0 replies; 96+ messages in thread
From: Kevin Hilman @ 2013-07-13 22:21 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Tony Lindgren, Rajendra Nayak, Linux OMAP Mailing List,
	vaibhav.bedia, linux-arm-kernel, mpfj-list, Sourav Poddar, paul

Felipe Balbi <balbi@ti.com> writes:

> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.

This part sounds a bit strange to me, and sounds more like a driver bug.
Looking at omap-serial, this probably happens because the driver calls
_use_autosuspend() after it has called _enable() but before has done its
_get_sync().

> Note that this patch was inspired by PCI's pci_pm_init().
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.

Excellent.

I like this approach, but agree it needs more testing like you
mentioned.

>  arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
>  1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
>  	return ret;
>  }
>  
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> +	omap_device_enable(pdev);
> +	pm_runtime_forbid(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	device_enable_async_suspend(&pdev->dev);

You don't comment in the changelog about what this is for.  I think we
probably want this, but I suspect it belongs in a follow-up patch with
its own changelog.

Also Like PCI, I think we also want the device_set_wakeup_capable() here
also, but that should have its own patch+changelog also.

Kevin

^ permalink raw reply	[flat|nested] 96+ messages in thread

* [PATCH] arm: omap2plus: unidle devices which are about to probe
@ 2013-07-13 22:21                                     ` Kevin Hilman
  0 siblings, 0 replies; 96+ messages in thread
From: Kevin Hilman @ 2013-07-13 22:21 UTC (permalink / raw)
  To: linux-arm-kernel

Felipe Balbi <balbi@ti.com> writes:

> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.

This part sounds a bit strange to me, and sounds more like a driver bug.
Looking at omap-serial, this probably happens because the driver calls
_use_autosuspend() after it has called _enable() but before has done its
_get_sync().

> Note that this patch was inspired by PCI's pci_pm_init().
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.

Excellent.

I like this approach, but agree it needs more testing like you
mentioned.

>  arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
>  1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
>  	return ret;
>  }
>  
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> +	omap_device_enable(pdev);
> +	pm_runtime_forbid(&pdev->dev);
> +	pm_runtime_set_active(&pdev->dev);
> +	device_enable_async_suspend(&pdev->dev);

You don't comment in the changelog about what this is for.  I think we
probably want this, but I suspect it belongs in a follow-up patch with
its own changelog.

Also Like PCI, I think we also want the device_set_wakeup_capable() here
also, but that should have its own patch+changelog also.

Kevin

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-12  0:40                                     ` Suman Anna
@ 2013-07-15  6:44                                       ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-15  6:44 UTC (permalink / raw)
  To: Suman Anna
  Cc: Grygorii Strashko, Tony Lindgren, Felipe Balbi, Kevin Hilman,
	Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar, Paul Walmsley

On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>> Hi,
>>
>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>
>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>> during probe.
>>>>>
>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>
>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>
>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>
>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>      initial state of the device, we will unidle the device
>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>      that the device is really active.
>> Don't think that it's good idea (
>> I've checked some driver's and think this patch will enable some devices
>> unpredictably:
>> - hwspinlock
>> - mailbox
>> - iommu
>> - ipu
>> All above devices need to be enabled on demand only (no
>> pm_runtime_get*() calls in probe). More over, some of them have very
>> specific enabling sequence - like ipu).
>>
>> May be Summan can say more on that.
> 
> Indeed, this is a problem for any of the slave processor devices.
> mailbox and iommu would be slaves to the remoteproc and the drivers have
> a specific sequence of bringing up a processor. The current
> hwmod/omap_device code is such that these devices will be left in reset
> and the driver code use the omap_device_(de)assert_hardreset API
> together with omap_device_enable code to bring up the devices. The
> remoteproc driver also needs to assert the resets (there are other
> problems associated with using omap_device_idle for remoteproc and
> iommu) for bringing up the devices after a suspend sequence. hwspinlock
> and mailbox may get away since they are in CORE domain, but definitely
> an issue for iommu and remoteproc. I would think that this would also
> affect other compute devices like IVAHD, ISS, SGX.

Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?

        /*
         * If an IP block contains HW reset lines and all of them are
         * asserted, we let integration code associated with that
         * block handle the enable.  We've received very little
         * information on what those driver authors need, and until
         * detailed information is provided and the driver code is
         * posted to the public lists, this is probably the best we
         * can do.
         */
        if (_are_all_hardreset_lines_asserted(oh))
                return 0;

What if this information is send back to omap_device() through a return value
so omap_device() knows about this too, so it avoids marking the omap device as
enabled? Wouldn't that fix the issue?


> 
> regards
> Suman
> 
>>
>>>>>
>>>>>      By the time driver's probe() is reached, a call to
>>>>>      pm_runtime_get_sync() will not cause driver's
>>>>>      ->runtime_resume() method to be called at first, only
>>>>>      after a successful ->runtime_suspend().
>>>>>
>>>>>      Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>>
>>>> btw, this is RFC, haven't tested at all.
>>>
>>> Yes it does not compile, then removing the extra ; at the end
>>> of the functions, it oopses with a NULL pointer exception.
>>>
>>> Regards,
>>>
>>> Tony
>>> -- 
>>> 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] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-15  6:44                                       ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-15  6:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>> Hi,
>>
>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>
>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>> during probe.
>>>>>
>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>
>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>
>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>
>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>      initial state of the device, we will unidle the device
>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>      that the device is really active.
>> Don't think that it's good idea (
>> I've checked some driver's and think this patch will enable some devices
>> unpredictably:
>> - hwspinlock
>> - mailbox
>> - iommu
>> - ipu
>> All above devices need to be enabled on demand only (no
>> pm_runtime_get*() calls in probe). More over, some of them have very
>> specific enabling sequence - like ipu).
>>
>> May be Summan can say more on that.
> 
> Indeed, this is a problem for any of the slave processor devices.
> mailbox and iommu would be slaves to the remoteproc and the drivers have
> a specific sequence of bringing up a processor. The current
> hwmod/omap_device code is such that these devices will be left in reset
> and the driver code use the omap_device_(de)assert_hardreset API
> together with omap_device_enable code to bring up the devices. The
> remoteproc driver also needs to assert the resets (there are other
> problems associated with using omap_device_idle for remoteproc and
> iommu) for bringing up the devices after a suspend sequence. hwspinlock
> and mailbox may get away since they are in CORE domain, but definitely
> an issue for iommu and remoteproc. I would think that this would also
> affect other compute devices like IVAHD, ISS, SGX.

Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?

        /*
         * If an IP block contains HW reset lines and all of them are
         * asserted, we let integration code associated with that
         * block handle the enable.  We've received very little
         * information on what those driver authors need, and until
         * detailed information is provided and the driver code is
         * posted to the public lists, this is probably the best we
         * can do.
         */
        if (_are_all_hardreset_lines_asserted(oh))
                return 0;

What if this information is send back to omap_device() through a return value
so omap_device() knows about this too, so it avoids marking the omap device as
enabled? Wouldn't that fix the issue?


> 
> regards
> Suman
> 
>>
>>>>>
>>>>>      By the time driver's probe() is reached, a call to
>>>>>      pm_runtime_get_sync() will not cause driver's
>>>>>      ->runtime_resume() method to be called at first, only
>>>>>      after a successful ->runtime_suspend().
>>>>>
>>>>>      Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>>
>>>> btw, this is RFC, haven't tested at all.
>>>
>>> Yes it does not compile, then removing the extra ; at the end
>>> of the functions, it oopses with a NULL pointer exception.
>>>
>>> Regards,
>>>
>>> Tony
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-15  6:44                                       ` Rajendra Nayak
@ 2013-07-15 10:01                                         ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-15 10:01 UTC (permalink / raw)
  To: Suman Anna
  Cc: Grygorii Strashko, Tony Lindgren, Felipe Balbi, Kevin Hilman,
	Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar, Paul Walmsley

On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>> Hi,
>>>
>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>>
>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>> during probe.
>>>>>>
>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>
>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>
>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>
>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>      initial state of the device, we will unidle the device
>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>      that the device is really active.
>>> Don't think that it's good idea (
>>> I've checked some driver's and think this patch will enable some devices
>>> unpredictably:
>>> - hwspinlock
>>> - mailbox
>>> - iommu
>>> - ipu
>>> All above devices need to be enabled on demand only (no
>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>> specific enabling sequence - like ipu).
>>>
>>> May be Summan can say more on that.
>>
>> Indeed, this is a problem for any of the slave processor devices.
>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>> a specific sequence of bringing up a processor. The current
>> hwmod/omap_device code is such that these devices will be left in reset
>> and the driver code use the omap_device_(de)assert_hardreset API
>> together with omap_device_enable code to bring up the devices. The
>> remoteproc driver also needs to assert the resets (there are other
>> problems associated with using omap_device_idle for remoteproc and
>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>> and mailbox may get away since they are in CORE domain, but definitely
>> an issue for iommu and remoteproc. I would think that this would also
>> affect other compute devices like IVAHD, ISS, SGX.
> 
> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
> 
>         /*
>          * If an IP block contains HW reset lines and all of them are
>          * asserted, we let integration code associated with that
>          * block handle the enable.  We've received very little
>          * information on what those driver authors need, and until
>          * detailed information is provided and the driver code is
>          * posted to the public lists, this is probably the best we
>          * can do.
>          */
>         if (_are_all_hardreset_lines_asserted(oh))
>                 return 0;
> 
> What if this information is send back to omap_device() through a return value
> so omap_device() knows about this too, so it avoids marking the omap device as
> enabled? Wouldn't that fix the issue?

I meant something like this..

>From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Mon, 15 Jul 2013 15:23:07 +0530
Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
 enable/idle/shutdown the hwmods

For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
enable/idle/shutdown operations as long as all the hard reset lines are
kept asserted. However it does not return an error back to the caller (in some
cases the omap_device layer) to communicate back the failure to operate on the
hwmod.

Fix this by making _enable()/_idle()/_shutdown() all return an error in such
cases, and also fix the omap_device layer to look at the return values coming
from hwmod operations before doing a omap_device level state transition.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_device.c |   20 ++++++++++----------
 arch/arm/mach-omap2/omap_hwmod.c  |    6 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..e89244b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -210,13 +210,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
  */
 static int _omap_device_enable_hwmods(struct omap_device *od)
 {
-	int i;
+	int i, ret = 0;
 
 	for (i = 0; i < od->hwmods_cnt; i++)
-		omap_hwmod_enable(od->hwmods[i]);
+		ret |= omap_hwmod_enable(od->hwmods[i]);
 
-	/* XXX pass along return value here? */
-	return 0;
+	return ret;
 }
 
 /**
@@ -227,13 +226,12 @@ static int _omap_device_enable_hwmods(struct omap_device *od)
  */
 static int _omap_device_idle_hwmods(struct omap_device *od)
 {
-	int i;
+	int i, ret = 0;
 
 	for (i = 0; i < od->hwmods_cnt; i++)
-		omap_hwmod_idle(od->hwmods[i]);
+		ret |= omap_hwmod_idle(od->hwmods[i]);
 
-	/* XXX pass along return value here? */
-	return 0;
+	return ret;
 }
 
 /* Public functions for use by core code */
@@ -697,7 +695,8 @@ int omap_device_enable(struct platform_device *pdev)
 
 	ret = _omap_device_enable_hwmods(od);
 
-	od->_state = OMAP_DEVICE_STATE_ENABLED;
+	if (!ret)
+		od->_state = OMAP_DEVICE_STATE_ENABLED;
 
 	return ret;
 }
@@ -727,7 +726,8 @@ int omap_device_idle(struct platform_device *pdev)
 
 	ret = _omap_device_idle_hwmods(od);
 
-	od->_state = OMAP_DEVICE_STATE_IDLE;
+	if (!ret)
+		od->_state = OMAP_DEVICE_STATE_IDLE;
 
 	return ret;
 }
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..07fd2a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2133,7 +2133,7 @@ static int _enable(struct omap_hwmod *oh)
 	 * can do.
 	 */
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
@@ -2222,7 +2222,7 @@ static int _idle(struct omap_hwmod *oh)
 	}
 
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	if (oh->class->sysc)
 		_idle_sysc(oh);
@@ -2276,7 +2276,7 @@ static int _shutdown(struct omap_hwmod *oh)
 	}
 
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	pr_debug("omap_hwmod: %s: disabling\n", oh->name);
 
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-15 10:01                                         ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-15 10:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>> Hi,
>>>
>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>>
>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>> during probe.
>>>>>>
>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>
>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>
>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>
>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>      initial state of the device, we will unidle the device
>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>      that the device is really active.
>>> Don't think that it's good idea (
>>> I've checked some driver's and think this patch will enable some devices
>>> unpredictably:
>>> - hwspinlock
>>> - mailbox
>>> - iommu
>>> - ipu
>>> All above devices need to be enabled on demand only (no
>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>> specific enabling sequence - like ipu).
>>>
>>> May be Summan can say more on that.
>>
>> Indeed, this is a problem for any of the slave processor devices.
>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>> a specific sequence of bringing up a processor. The current
>> hwmod/omap_device code is such that these devices will be left in reset
>> and the driver code use the omap_device_(de)assert_hardreset API
>> together with omap_device_enable code to bring up the devices. The
>> remoteproc driver also needs to assert the resets (there are other
>> problems associated with using omap_device_idle for remoteproc and
>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>> and mailbox may get away since they are in CORE domain, but definitely
>> an issue for iommu and remoteproc. I would think that this would also
>> affect other compute devices like IVAHD, ISS, SGX.
> 
> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
> 
>         /*
>          * If an IP block contains HW reset lines and all of them are
>          * asserted, we let integration code associated with that
>          * block handle the enable.  We've received very little
>          * information on what those driver authors need, and until
>          * detailed information is provided and the driver code is
>          * posted to the public lists, this is probably the best we
>          * can do.
>          */
>         if (_are_all_hardreset_lines_asserted(oh))
>                 return 0;
> 
> What if this information is send back to omap_device() through a return value
> so omap_device() knows about this too, so it avoids marking the omap device as
> enabled? Wouldn't that fix the issue?

I meant something like this..

>From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak <rnayak@ti.com>
Date: Mon, 15 Jul 2013 15:23:07 +0530
Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
 enable/idle/shutdown the hwmods

For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
enable/idle/shutdown operations as long as all the hard reset lines are
kept asserted. However it does not return an error back to the caller (in some
cases the omap_device layer) to communicate back the failure to operate on the
hwmod.

Fix this by making _enable()/_idle()/_shutdown() all return an error in such
cases, and also fix the omap_device layer to look at the return values coming
from hwmod operations before doing a omap_device level state transition.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_device.c |   20 ++++++++++----------
 arch/arm/mach-omap2/omap_hwmod.c  |    6 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..e89244b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -210,13 +210,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
  */
 static int _omap_device_enable_hwmods(struct omap_device *od)
 {
-	int i;
+	int i, ret = 0;
 
 	for (i = 0; i < od->hwmods_cnt; i++)
-		omap_hwmod_enable(od->hwmods[i]);
+		ret |= omap_hwmod_enable(od->hwmods[i]);
 
-	/* XXX pass along return value here? */
-	return 0;
+	return ret;
 }
 
 /**
@@ -227,13 +226,12 @@ static int _omap_device_enable_hwmods(struct omap_device *od)
  */
 static int _omap_device_idle_hwmods(struct omap_device *od)
 {
-	int i;
+	int i, ret = 0;
 
 	for (i = 0; i < od->hwmods_cnt; i++)
-		omap_hwmod_idle(od->hwmods[i]);
+		ret |= omap_hwmod_idle(od->hwmods[i]);
 
-	/* XXX pass along return value here? */
-	return 0;
+	return ret;
 }
 
 /* Public functions for use by core code */
@@ -697,7 +695,8 @@ int omap_device_enable(struct platform_device *pdev)
 
 	ret = _omap_device_enable_hwmods(od);
 
-	od->_state = OMAP_DEVICE_STATE_ENABLED;
+	if (!ret)
+		od->_state = OMAP_DEVICE_STATE_ENABLED;
 
 	return ret;
 }
@@ -727,7 +726,8 @@ int omap_device_idle(struct platform_device *pdev)
 
 	ret = _omap_device_idle_hwmods(od);
 
-	od->_state = OMAP_DEVICE_STATE_IDLE;
+	if (!ret)
+		od->_state = OMAP_DEVICE_STATE_IDLE;
 
 	return ret;
 }
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..07fd2a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2133,7 +2133,7 @@ static int _enable(struct omap_hwmod *oh)
 	 * can do.
 	 */
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
@@ -2222,7 +2222,7 @@ static int _idle(struct omap_hwmod *oh)
 	}
 
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	if (oh->class->sysc)
 		_idle_sysc(oh);
@@ -2276,7 +2276,7 @@ static int _shutdown(struct omap_hwmod *oh)
 	}
 
 	if (_are_all_hardreset_lines_asserted(oh))
-		return 0;
+		return -EPERM;
 
 	pr_debug("omap_hwmod: %s: disabling\n", oh->name);
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-15 10:01                                         ` Rajendra Nayak
@ 2013-07-15 19:23                                           ` Suman Anna
  -1 siblings, 0 replies; 96+ messages in thread
From: Suman Anna @ 2013-07-15 19:23 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Grygorii Strashko, Tony Lindgren, Felipe Balbi, Kevin Hilman,
	Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar, Paul Walmsley

On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>> Hi,
>>>>
>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>>>
>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>> during probe.
>>>>>>>
>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>
>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>>
>>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>>
>>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>>      initial state of the device, we will unidle the device
>>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>      that the device is really active.
>>>> Don't think that it's good idea (
>>>> I've checked some driver's and think this patch will enable some devices
>>>> unpredictably:
>>>> - hwspinlock
>>>> - mailbox
>>>> - iommu
>>>> - ipu
>>>> All above devices need to be enabled on demand only (no
>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>> specific enabling sequence - like ipu).
>>>>
>>>> May be Summan can say more on that.
>>>
>>> Indeed, this is a problem for any of the slave processor devices.
>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>> a specific sequence of bringing up a processor. The current
>>> hwmod/omap_device code is such that these devices will be left in reset
>>> and the driver code use the omap_device_(de)assert_hardreset API
>>> together with omap_device_enable code to bring up the devices. The
>>> remoteproc driver also needs to assert the resets (there are other
>>> problems associated with using omap_device_idle for remoteproc and
>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>> and mailbox may get away since they are in CORE domain, but definitely
>>> an issue for iommu and remoteproc. I would think that this would also
>>> affect other compute devices like IVAHD, ISS, SGX.
>>
>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?

Yes, the omap_device_enable bails out if the reset lines are still
asserted, and the driver code deals with the resets currently. This code
essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
added to the corresponding hwmods - we do not want the hwmod/omap_device
code to enable the processor IPs and leave the enabling/device
management to the driver.

>>
>>         /*
>>          * If an IP block contains HW reset lines and all of them are
>>          * asserted, we let integration code associated with that
>>          * block handle the enable.  We've received very little
>>          * information on what those driver authors need, and until
>>          * detailed information is provided and the driver code is
>>          * posted to the public lists, this is probably the best we
>>          * can do.
>>          */
>>         if (_are_all_hardreset_lines_asserted(oh))
>>                 return 0;
>>
>> What if this information is send back to omap_device() through a return value
>> so omap_device() knows about this too, so it avoids marking the omap device as
>> enabled? Wouldn't that fix the issue?
> 
> I meant something like this..
> 
> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak <rnayak@ti.com>
> Date: Mon, 15 Jul 2013 15:23:07 +0530
> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>  enable/idle/shutdown the hwmods
> 
> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
> enable/idle/shutdown operations as long as all the hard reset lines are
> kept asserted. However it does not return an error back to the caller (in some
> cases the omap_device layer) to communicate back the failure to operate on the
> hwmod.
> 
> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
> cases, and also fix the omap_device layer to look at the return values coming
> from hwmod operations before doing a omap_device level state transition.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>

Let me test this and get back to you if there are any issues.

regards
Suman


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-15 19:23                                           ` Suman Anna
  0 siblings, 0 replies; 96+ messages in thread
From: Suman Anna @ 2013-07-15 19:23 UTC (permalink / raw)
  To: linux-arm-kernel

On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>> Hi,
>>>>
>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>>>
>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>> during probe.
>>>>>>>
>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>
>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>>
>>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>>
>>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>>      initial state of the device, we will unidle the device
>>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>      that the device is really active.
>>>> Don't think that it's good idea (
>>>> I've checked some driver's and think this patch will enable some devices
>>>> unpredictably:
>>>> - hwspinlock
>>>> - mailbox
>>>> - iommu
>>>> - ipu
>>>> All above devices need to be enabled on demand only (no
>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>> specific enabling sequence - like ipu).
>>>>
>>>> May be Summan can say more on that.
>>>
>>> Indeed, this is a problem for any of the slave processor devices.
>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>> a specific sequence of bringing up a processor. The current
>>> hwmod/omap_device code is such that these devices will be left in reset
>>> and the driver code use the omap_device_(de)assert_hardreset API
>>> together with omap_device_enable code to bring up the devices. The
>>> remoteproc driver also needs to assert the resets (there are other
>>> problems associated with using omap_device_idle for remoteproc and
>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>> and mailbox may get away since they are in CORE domain, but definitely
>>> an issue for iommu and remoteproc. I would think that this would also
>>> affect other compute devices like IVAHD, ISS, SGX.
>>
>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?

Yes, the omap_device_enable bails out if the reset lines are still
asserted, and the driver code deals with the resets currently. This code
essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
added to the corresponding hwmods - we do not want the hwmod/omap_device
code to enable the processor IPs and leave the enabling/device
management to the driver.

>>
>>         /*
>>          * If an IP block contains HW reset lines and all of them are
>>          * asserted, we let integration code associated with that
>>          * block handle the enable.  We've received very little
>>          * information on what those driver authors need, and until
>>          * detailed information is provided and the driver code is
>>          * posted to the public lists, this is probably the best we
>>          * can do.
>>          */
>>         if (_are_all_hardreset_lines_asserted(oh))
>>                 return 0;
>>
>> What if this information is send back to omap_device() through a return value
>> so omap_device() knows about this too, so it avoids marking the omap device as
>> enabled? Wouldn't that fix the issue?
> 
> I meant something like this..
> 
> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
> From: Rajendra Nayak <rnayak@ti.com>
> Date: Mon, 15 Jul 2013 15:23:07 +0530
> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>  enable/idle/shutdown the hwmods
> 
> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
> enable/idle/shutdown operations as long as all the hard reset lines are
> kept asserted. However it does not return an error back to the caller (in some
> cases the omap_device layer) to communicate back the failure to operate on the
> hwmod.
> 
> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
> cases, and also fix the omap_device layer to look at the return values coming
> from hwmod operations before doing a omap_device level state transition.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>

Let me test this and get back to you if there are any issues.

regards
Suman

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-15 19:23                                           ` Suman Anna
@ 2013-07-16  6:30                                             ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-16  6:30 UTC (permalink / raw)
  To: Suman Anna
  Cc: Grygorii Strashko, Tony Lindgren, Felipe Balbi, Kevin Hilman,
	Bedia, Vaibhav, linux-omap, linux-arm-kernel, Mark Jackson,
	Sourav Poddar, Paul Walmsley

On Tuesday 16 July 2013 12:53 AM, Suman Anna wrote:
> On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
>> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>>> Hi,
>>>>>
>>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>>>>
>>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>>> during probe.
>>>>>>>>
>>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>>
>>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>>>
>>>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>>>
>>>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>>>      initial state of the device, we will unidle the device
>>>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>>      that the device is really active.
>>>>> Don't think that it's good idea (
>>>>> I've checked some driver's and think this patch will enable some devices
>>>>> unpredictably:
>>>>> - hwspinlock
>>>>> - mailbox
>>>>> - iommu
>>>>> - ipu
>>>>> All above devices need to be enabled on demand only (no
>>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>>> specific enabling sequence - like ipu).
>>>>>
>>>>> May be Summan can say more on that.
>>>>
>>>> Indeed, this is a problem for any of the slave processor devices.
>>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>>> a specific sequence of bringing up a processor. The current
>>>> hwmod/omap_device code is such that these devices will be left in reset
>>>> and the driver code use the omap_device_(de)assert_hardreset API
>>>> together with omap_device_enable code to bring up the devices. The
>>>> remoteproc driver also needs to assert the resets (there are other
>>>> problems associated with using omap_device_idle for remoteproc and
>>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>>> and mailbox may get away since they are in CORE domain, but definitely
>>>> an issue for iommu and remoteproc. I would think that this would also
>>>> affect other compute devices like IVAHD, ISS, SGX.
>>>
>>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
> 
> Yes, the omap_device_enable bails out if the reset lines are still
> asserted, and the driver code deals with the resets currently. This code
> essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
> added to the corresponding hwmods - we do not want the hwmod/omap_device
> code to enable the processor IPs and leave the enabling/device
> management to the driver.
> 
>>>
>>>         /*
>>>          * If an IP block contains HW reset lines and all of them are
>>>          * asserted, we let integration code associated with that
>>>          * block handle the enable.  We've received very little
>>>          * information on what those driver authors need, and until
>>>          * detailed information is provided and the driver code is
>>>          * posted to the public lists, this is probably the best we
>>>          * can do.
>>>          */
>>>         if (_are_all_hardreset_lines_asserted(oh))
>>>                 return 0;
>>>
>>> What if this information is send back to omap_device() through a return value
>>> so omap_device() knows about this too, so it avoids marking the omap device as
>>> enabled? Wouldn't that fix the issue?
>>
>> I meant something like this..
>>
>> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
>> From: Rajendra Nayak <rnayak@ti.com>
>> Date: Mon, 15 Jul 2013 15:23:07 +0530
>> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>>  enable/idle/shutdown the hwmods
>>
>> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
>> enable/idle/shutdown operations as long as all the hard reset lines are
>> kept asserted. However it does not return an error back to the caller (in some
>> cases the omap_device layer) to communicate back the failure to operate on the
>> hwmod.
>>
>> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
>> cases, and also fix the omap_device layer to look at the return values coming
>> from hwmod operations before doing a omap_device level state transition.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> 
> Let me test this and get back to you if there are any issues.

Great, thanks for testing.

> 
> regards
> Suman
> 


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-16  6:30                                             ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-16  6:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday 16 July 2013 12:53 AM, Suman Anna wrote:
> On 07/15/2013 05:01 AM, Rajendra Nayak wrote:
>> On Monday 15 July 2013 12:14 PM, Rajendra Nayak wrote:
>>> On Friday 12 July 2013 06:10 AM, Suman Anna wrote:
>>>> On 07/11/2013 04:59 AM, Grygorii Strashko wrote:
>>>>> Hi,
>>>>>
>>>>> On 07/11/2013 09:32 AM, Tony Lindgren wrote:
>>>>>> * Felipe Balbi <balbi@ti.com> [130710 09:18]:
>>>>>>>
>>>>>>> On Wed, Jul 10, 2013 at 07:07:04PM +0300, Felipe Balbi wrote:
>>>>>>>> how about something like below ? It makes omap_device/hwmod and
>>>>>>>> pm_runtime agree on the initial state of the device and will prevent
>>>>>>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>>>>>>> during probe.
>>>>>>>>
>>>>>>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>>>>>>>
>>>>>>>> commit 59108a500b4ab4b1a5102648a3360276dbf7df6f
>>>>>>>> Author: Felipe Balbi <balbi@ti.com>
>>>>>>>> Date:   Wed Jul 10 18:50:16 2013 +0300
>>>>>>>>
>>>>>>>>      arm: omap2plus: unidle devices which are about to probe
>>>>>>>>
>>>>>>>>      in order to make HWMOD and pm_runtime agree on the
>>>>>>>>      initial state of the device, we will unidle the device
>>>>>>>>      and call pm_runtime_set_active() to tell pm_runtime
>>>>>>>>      that the device is really active.
>>>>> Don't think that it's good idea (
>>>>> I've checked some driver's and think this patch will enable some devices
>>>>> unpredictably:
>>>>> - hwspinlock
>>>>> - mailbox
>>>>> - iommu
>>>>> - ipu
>>>>> All above devices need to be enabled on demand only (no
>>>>> pm_runtime_get*() calls in probe). More over, some of them have very
>>>>> specific enabling sequence - like ipu).
>>>>>
>>>>> May be Summan can say more on that.
>>>>
>>>> Indeed, this is a problem for any of the slave processor devices.
>>>> mailbox and iommu would be slaves to the remoteproc and the drivers have
>>>> a specific sequence of bringing up a processor. The current
>>>> hwmod/omap_device code is such that these devices will be left in reset
>>>> and the driver code use the omap_device_(de)assert_hardreset API
>>>> together with omap_device_enable code to bring up the devices. The
>>>> remoteproc driver also needs to assert the resets (there are other
>>>> problems associated with using omap_device_idle for remoteproc and
>>>> iommu) for bringing up the devices after a suspend sequence. hwspinlock
>>>> and mailbox may get away since they are in CORE domain, but definitely
>>>> an issue for iommu and remoteproc. I would think that this would also
>>>> affect other compute devices like IVAHD, ISS, SGX.
>>>
>>> Today, for these IPs I guess hwmod waits for the resets to be de-asserted, right?
> 
> Yes, the omap_device_enable bails out if the reset lines are still
> asserted, and the driver code deals with the resets currently. This code
> essentially achieves the same as if a HWMOD_INIT_NO_RESET flag is
> added to the corresponding hwmods - we do not want the hwmod/omap_device
> code to enable the processor IPs and leave the enabling/device
> management to the driver.
> 
>>>
>>>         /*
>>>          * If an IP block contains HW reset lines and all of them are
>>>          * asserted, we let integration code associated with that
>>>          * block handle the enable.  We've received very little
>>>          * information on what those driver authors need, and until
>>>          * detailed information is provided and the driver code is
>>>          * posted to the public lists, this is probably the best we
>>>          * can do.
>>>          */
>>>         if (_are_all_hardreset_lines_asserted(oh))
>>>                 return 0;
>>>
>>> What if this information is send back to omap_device() through a return value
>>> so omap_device() knows about this too, so it avoids marking the omap device as
>>> enabled? Wouldn't that fix the issue?
>>
>> I meant something like this..
>>
>> From 2fbea0dde0f72897089ef2e8e441b5e5bd6ea967 Mon Sep 17 00:00:00 2001
>> From: Rajendra Nayak <rnayak@ti.com>
>> Date: Mon, 15 Jul 2013 15:23:07 +0530
>> Subject: [PATCH] ARM: OMAP2+: Make omap_device aware of hwmod failing to
>>  enable/idle/shutdown the hwmods
>>
>> For IP blocks (mainly processors) which have hard reset lines, hwmod avoids
>> enable/idle/shutdown operations as long as all the hard reset lines are
>> kept asserted. However it does not return an error back to the caller (in some
>> cases the omap_device layer) to communicate back the failure to operate on the
>> hwmod.
>>
>> Fix this by making _enable()/_idle()/_shutdown() all return an error in such
>> cases, and also fix the omap_device layer to look at the return values coming
>> from hwmod operations before doing a omap_device level state transition.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> 
> Let me test this and get back to you if there are any issues.

Great, thanks for testing.

> 
> regards
> Suman
> 

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-11  9:17                               ` Rajendra Nayak
@ 2013-07-16 10:27                                 ` Grygorii Strashko
  -1 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-16 10:27 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: balbi, Tony Lindgren, Kevin Hilman, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

Hi Rajendra,

On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
>
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
>
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>          int delay = dev->power.autosuspend_delay;
>
>          /* Should runtime suspend be prevented now? */
>          if (dev->power.use_autosuspend && delay < 0) {
>
>                  /* If it used to be allowed then prevent it. */
>                  if (!old_use || old_delay >= 0) {
>                          atomic_inc(&dev->power.usage_count);
>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>                  }
>          }
> -----
>
> So we end up with the same issue with serial resume being called before set_termios()
>
> [1]
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..c71d47d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>          struct device_node *node = pdev->dev.of_node;
>          const char *oh_name;
>          int oh_cnt, i, ret = 0;
> +       bool device_active = false;
>
>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>          if (oh_cnt <= 0) {
> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>                          goto odbfd_exit1;
>                  }
>                  hwmods[i] = oh;
> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
> +                       device_active = true;
> +
>          }
>
>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>
>          pdev->dev.pm_domain = &omap_device_pm_domain;
>
> +       if (device_active) {
> +               omap_device_enable(pdev);
> +               pm_runtime_set_active(&pdev->dev);
> +       }
> +
>   odbfd_exit1:
>          kfree(hwmods);
>   odbfd_exit:

This solution works good for me in combination with
"serial: omap: enable PM runtime only when its fully configured"
http://www.spinics.net/lists/linux-serial/msg10317.html
(earlyprintk use case)

And I think the best way would be to move forward with yours solution.
- it will affect only on needed IPs drivers - not on all, so no issues 
with iommu and etc.

But issue with *non console" UARTs will still be here and, I think,
there are no way ti solve it from OMAP device/hwmod frameworks side,
because only driver can know when his context is ready.
To test do: #echo 0xDEAD > dev/ttyO3

Regards,
-grygorii

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-16 10:27                                 ` Grygorii Strashko
  0 siblings, 0 replies; 96+ messages in thread
From: Grygorii Strashko @ 2013-07-16 10:27 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Rajendra,

On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>> how about something like below ? It makes omap_device/hwmod and
>> pm_runtime agree on the initial state of the device and will prevent
>> ->runtime_resume() from being called on first pm_runtime_get*() done
>> during probe.
>>
>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>
> I tried something similar [1] but what I found is that the serial
> runtime resume was called despite it being marked as active using
> pm_runtime_set_active().
>
> That seems to be because of the pm_runtime_set_autosuspend_delay()
> because we have the autosuspend_delay = -1
>
> -----
> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
> {
>          int delay = dev->power.autosuspend_delay;
>
>          /* Should runtime suspend be prevented now? */
>          if (dev->power.use_autosuspend && delay < 0) {
>
>                  /* If it used to be allowed then prevent it. */
>                  if (!old_use || old_delay >= 0) {
>                          atomic_inc(&dev->power.usage_count);
>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>                  }
>          }
> -----
>
> So we end up with the same issue with serial resume being called before set_termios()
>
> [1]
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..c71d47d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>          struct device_node *node = pdev->dev.of_node;
>          const char *oh_name;
>          int oh_cnt, i, ret = 0;
> +       bool device_active = false;
>
>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>          if (oh_cnt <= 0) {
> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>                          goto odbfd_exit1;
>                  }
>                  hwmods[i] = oh;
> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
> +                       device_active = true;
> +
>          }
>
>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>
>          pdev->dev.pm_domain = &omap_device_pm_domain;
>
> +       if (device_active) {
> +               omap_device_enable(pdev);
> +               pm_runtime_set_active(&pdev->dev);
> +       }
> +
>   odbfd_exit1:
>          kfree(hwmods);
>   odbfd_exit:

This solution works good for me in combination with
"serial: omap: enable PM runtime only when its fully configured"
http://www.spinics.net/lists/linux-serial/msg10317.html
(earlyprintk use case)

And I think the best way would be to move forward with yours solution.
- it will affect only on needed IPs drivers - not on all, so no issues 
with iommu and etc.

But issue with *non console" UARTs will still be here and, I think,
there are no way ti solve it from OMAP device/hwmod frameworks side,
because only driver can know when his context is ready.
To test do: #echo 0xDEAD > dev/ttyO3

Regards,
-grygorii

^ permalink raw reply	[flat|nested] 96+ messages in thread

* Re: Boot hang regression 3.10.0-rc4 -> 3.10.0
  2013-07-16 10:27                                 ` Grygorii Strashko
@ 2013-07-17  7:10                                   ` Rajendra Nayak
  -1 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-17  7:10 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: balbi, Tony Lindgren, Kevin Hilman, Bedia, Vaibhav, linux-omap,
	linux-arm-kernel, Mark Jackson, Sourav Poddar, Paul Walmsley

On Tuesday 16 July 2013 03:57 PM, Grygorii Strashko wrote:
> Hi Rajendra,
> 
> On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
>> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>>> how about something like below ? It makes omap_device/hwmod and
>>> pm_runtime agree on the initial state of the device and will prevent
>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>> during probe.
>>>
>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>
>> I tried something similar [1] but what I found is that the serial
>> runtime resume was called despite it being marked as active using
>> pm_runtime_set_active().
>>
>> That seems to be because of the pm_runtime_set_autosuspend_delay()
>> because we have the autosuspend_delay = -1
>>
>> -----
>> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
>> {
>>          int delay = dev->power.autosuspend_delay;
>>
>>          /* Should runtime suspend be prevented now? */
>>          if (dev->power.use_autosuspend && delay < 0) {
>>
>>                  /* If it used to be allowed then prevent it. */
>>                  if (!old_use || old_delay >= 0) {
>>                          atomic_inc(&dev->power.usage_count);
>>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>>                  }
>>          }
>> -----
>>
>> So we end up with the same issue with serial resume being called before set_termios()
>>
>> [1]
>>
>> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
>> index 5cc9287..c71d47d 100644
>> --- a/arch/arm/mach-omap2/omap_device.c
>> +++ b/arch/arm/mach-omap2/omap_device.c
>> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>          struct device_node *node = pdev->dev.of_node;
>>          const char *oh_name;
>>          int oh_cnt, i, ret = 0;
>> +       bool device_active = false;
>>
>>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>>          if (oh_cnt <= 0) {
>> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>                          goto odbfd_exit1;
>>                  }
>>                  hwmods[i] = oh;
>> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
>> +                       device_active = true;
>> +
>>          }
>>
>>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
>> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>
>>          pdev->dev.pm_domain = &omap_device_pm_domain;
>>
>> +       if (device_active) {
>> +               omap_device_enable(pdev);
>> +               pm_runtime_set_active(&pdev->dev);
>> +       }
>> +
>>   odbfd_exit1:
>>          kfree(hwmods);
>>   odbfd_exit:
> 
> This solution works good for me in combination with
> "serial: omap: enable PM runtime only when its fully configured"
> http://www.spinics.net/lists/linux-serial/msg10317.html
> (earlyprintk use case)
> 
> And I think the best way would be to move forward with yours solution.
> - it will affect only on needed IPs drivers - not on all, so no issues with iommu and etc.

Ok, good to know that this solution works. Anyone has any other thoughts on whats the best
way to fix this for the -rcs? (Note that we have bootup broken on all OMAPs with DEBUG_LL
for now, atleast for all DT only platforms)

The other option of course is to use the patch posted by Felipe [1], thought that had issues
handling processor IPs as pointed out by Grygorii and Suman [2], the fix I posted [3] to make
omap_device aware of hwmod bypassing these IPs might fix some of those, but this solution in
general would need more testing as it affects all modules on the bus.

[1] http://www.spinics.net/lists/arm-kernel/msg258062.html
[2] http://www.spinics.net/lists/arm-kernel/msg258061.html
[3] http://www.spinics.net/lists/arm-kernel/msg258465.html

> 
> But issue with *non console" UARTs will still be here and, I think,
> there are no way ti solve it from OMAP device/hwmod frameworks side,
> because only driver can know when his context is ready.
> To test do: #echo 0xDEAD > dev/ttyO3
> 
> Regards,
> -grygorii


^ permalink raw reply	[flat|nested] 96+ messages in thread

* Boot hang regression 3.10.0-rc4 -> 3.10.0
@ 2013-07-17  7:10                                   ` Rajendra Nayak
  0 siblings, 0 replies; 96+ messages in thread
From: Rajendra Nayak @ 2013-07-17  7:10 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday 16 July 2013 03:57 PM, Grygorii Strashko wrote:
> Hi Rajendra,
> 
> On 07/11/2013 12:17 PM, Rajendra Nayak wrote:
>> On Wednesday 10 July 2013 09:37 PM, Felipe Balbi wrote:
>>> how about something like below ? It makes omap_device/hwmod and
>>> pm_runtime agree on the initial state of the device and will prevent
>>> ->runtime_resume() from being called on first pm_runtime_get*() done
>>> during probe.
>>>
>>> This is similar to what PCI bus does (if you look at pci_pm_init()).
>>
>> I tried something similar [1] but what I found is that the serial
>> runtime resume was called despite it being marked as active using
>> pm_runtime_set_active().
>>
>> That seems to be because of the pm_runtime_set_autosuspend_delay()
>> because we have the autosuspend_delay = -1
>>
>> -----
>> static void update_autosuspend(struct device *dev, int old_delay, int old_use)
>> {
>>          int delay = dev->power.autosuspend_delay;
>>
>>          /* Should runtime suspend be prevented now? */
>>          if (dev->power.use_autosuspend && delay < 0) {
>>
>>                  /* If it used to be allowed then prevent it. */
>>                  if (!old_use || old_delay >= 0) {
>>                          atomic_inc(&dev->power.usage_count);
>>                          rpm_resume(dev, 0); <------------------------------- calls serial runtime resume.
>>                  }
>>          }
>> -----
>>
>> So we end up with the same issue with serial resume being called before set_termios()
>>
>> [1]
>>
>> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
>> index 5cc9287..c71d47d 100644
>> --- a/arch/arm/mach-omap2/omap_device.c
>> +++ b/arch/arm/mach-omap2/omap_device.c
>> @@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>          struct device_node *node = pdev->dev.of_node;
>>          const char *oh_name;
>>          int oh_cnt, i, ret = 0;
>> +       bool device_active = false;
>>
>>          oh_cnt = of_property_count_strings(node, "ti,hwmods");
>>          if (oh_cnt <= 0) {
>> @@ -152,6 +153,9 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>                          goto odbfd_exit1;
>>                  }
>>                  hwmods[i] = oh;
>> +               if (oh->flags & HWMOD_INIT_NO_IDLE)
>> +                       device_active = true;
>> +
>>          }
>>
>>          od = omap_device_alloc(pdev, hwmods, oh_cnt);
>> @@ -172,6 +176,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
>>
>>          pdev->dev.pm_domain = &omap_device_pm_domain;
>>
>> +       if (device_active) {
>> +               omap_device_enable(pdev);
>> +               pm_runtime_set_active(&pdev->dev);
>> +       }
>> +
>>   odbfd_exit1:
>>          kfree(hwmods);
>>   odbfd_exit:
> 
> This solution works good for me in combination with
> "serial: omap: enable PM runtime only when its fully configured"
> http://www.spinics.net/lists/linux-serial/msg10317.html
> (earlyprintk use case)
> 
> And I think the best way would be to move forward with yours solution.
> - it will affect only on needed IPs drivers - not on all, so no issues with iommu and etc.

Ok, good to know that this solution works. Anyone has any other thoughts on whats the best
way to fix this for the -rcs? (Note that we have bootup broken on all OMAPs with DEBUG_LL
for now, atleast for all DT only platforms)

The other option of course is to use the patch posted by Felipe [1], thought that had issues
handling processor IPs as pointed out by Grygorii and Suman [2], the fix I posted [3] to make
omap_device aware of hwmod bypassing these IPs might fix some of those, but this solution in
general would need more testing as it affects all modules on the bus.

[1] http://www.spinics.net/lists/arm-kernel/msg258062.html
[2] http://www.spinics.net/lists/arm-kernel/msg258061.html
[3] http://www.spinics.net/lists/arm-kernel/msg258465.html

> 
> But issue with *non console" UARTs will still be here and, I think,
> there are no way ti solve it from OMAP device/hwmod frameworks side,
> because only driver can know when his context is ready.
> To test do: #echo 0xDEAD > dev/ttyO3
> 
> Regards,
> -grygorii

^ permalink raw reply	[flat|nested] 96+ messages in thread

end of thread, other threads:[~2013-07-17  7:11 UTC | newest]

Thread overview: 96+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-04 13:25 Boot hang regression 3.10.0-rc4 -> 3.10.0 Mark Jackson
2013-07-04 13:25 ` Mark Jackson
2013-07-04 15:14 ` Mark Jackson
2013-07-04 15:14   ` Mark Jackson
2013-07-04 16:00   ` Mark Jackson
2013-07-04 16:00     ` Mark Jackson
2013-07-05  8:11     ` Bedia, Vaibhav
2013-07-05  8:11       ` Bedia, Vaibhav
2013-07-05 11:59       ` Tony Lindgren
2013-07-05 11:59         ` Tony Lindgren
2013-07-05 13:20         ` Bedia, Vaibhav
2013-07-05 13:20           ` Bedia, Vaibhav
2013-07-05 13:31           ` Bedia, Vaibhav
2013-07-05 13:31             ` Bedia, Vaibhav
2013-07-08 11:25             ` Tony Lindgren
2013-07-08 11:25               ` Tony Lindgren
2013-07-08 12:16               ` Tony Lindgren
2013-07-08 12:16                 ` Tony Lindgren
2013-07-08 12:41               ` Rajendra Nayak
2013-07-08 12:41                 ` Rajendra Nayak
2013-07-08 13:10                 ` Tony Lindgren
2013-07-08 13:10                   ` Tony Lindgren
2013-07-08 13:20                   ` Rajendra Nayak
2013-07-08 13:20                     ` Rajendra Nayak
2013-07-08 13:25                     ` Rajendra Nayak
2013-07-08 13:25                       ` Rajendra Nayak
2013-07-08 13:35                     ` Felipe Balbi
2013-07-08 13:35                       ` Felipe Balbi
2013-07-09  5:33                       ` Rajendra Nayak
2013-07-09  5:33                         ` Rajendra Nayak
2013-07-09  6:42                         ` Felipe Balbi
2013-07-09  6:42                           ` Felipe Balbi
2013-07-09  7:19                           ` Rajendra Nayak
2013-07-09  7:19                             ` Rajendra Nayak
2013-07-09  7:40                             ` Felipe Balbi
2013-07-09  7:40                               ` Felipe Balbi
2013-07-09 18:59                           ` Grygorii Strashko
2013-07-09 18:59                             ` Grygorii Strashko
2013-07-09 19:41                             ` Felipe Balbi
2013-07-09 19:41                               ` Felipe Balbi
2013-07-10 12:16                               ` Grygorii Strashko
2013-07-10 12:16                                 ` Grygorii Strashko
2013-07-10 12:25                                 ` Felipe Balbi
2013-07-10 12:25                                   ` Felipe Balbi
2013-07-10  8:22                       ` Kevin Hilman
2013-07-10  8:22                         ` Kevin Hilman
2013-07-10 12:10                         ` Tony Lindgren
2013-07-10 12:10                           ` Tony Lindgren
2013-07-10 12:27                           ` Tony Lindgren
2013-07-10 12:27                             ` Tony Lindgren
2013-07-10 14:26                         ` Tony Lindgren
2013-07-10 14:26                           ` Tony Lindgren
2013-07-10 16:07                           ` Felipe Balbi
2013-07-10 16:07                             ` Felipe Balbi
2013-07-10 16:11                             ` Felipe Balbi
2013-07-10 16:11                               ` Felipe Balbi
2013-07-11  6:32                               ` Tony Lindgren
2013-07-11  6:32                                 ` Tony Lindgren
2013-07-11  9:59                                 ` Grygorii Strashko
2013-07-11  9:59                                   ` Grygorii Strashko
2013-07-12  0:40                                   ` Suman Anna
2013-07-12  0:40                                     ` Suman Anna
2013-07-15  6:44                                     ` Rajendra Nayak
2013-07-15  6:44                                       ` Rajendra Nayak
2013-07-15 10:01                                       ` Rajendra Nayak
2013-07-15 10:01                                         ` Rajendra Nayak
2013-07-15 19:23                                         ` Suman Anna
2013-07-15 19:23                                           ` Suman Anna
2013-07-16  6:30                                           ` Rajendra Nayak
2013-07-16  6:30                                             ` Rajendra Nayak
2013-07-11  9:17                             ` Rajendra Nayak
2013-07-11  9:17                               ` Rajendra Nayak
2013-07-11  9:26                               ` Felipe Balbi
2013-07-11  9:26                                 ` Felipe Balbi
2013-07-11 10:16                                 ` [PATCH] arm: omap2plus: unidle devices which are about to probe Felipe Balbi
2013-07-11 10:16                                   ` Felipe Balbi
2013-07-12 11:58                                   ` Grygorii Strashko
2013-07-12 11:58                                     ` Grygorii Strashko
2013-07-12 12:10                                     ` Felipe Balbi
2013-07-12 12:10                                       ` Felipe Balbi
2013-07-12 12:27                                       ` Rajendra Nayak
2013-07-12 12:27                                         ` Rajendra Nayak
2013-07-13 22:21                                   ` Kevin Hilman
2013-07-13 22:21                                     ` Kevin Hilman
2013-07-11  9:59                               ` Boot hang regression 3.10.0-rc4 -> 3.10.0 Grygorii Strashko
2013-07-11  9:59                                 ` Grygorii Strashko
2013-07-16 10:27                               ` Grygorii Strashko
2013-07-16 10:27                                 ` Grygorii Strashko
2013-07-17  7:10                                 ` Rajendra Nayak
2013-07-17  7:10                                   ` Rajendra Nayak
2013-07-11  6:18                           ` Rajendra Nayak
2013-07-11  6:18                             ` Rajendra Nayak
2013-07-11  6:24                             ` Tony Lindgren
2013-07-11  6:24                               ` Tony Lindgren
2013-07-11  9:11                               ` Rajendra Nayak
2013-07-11  9:11                                 ` Rajendra Nayak

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.