* [PATCH 00/11] OMAP3 CPUidle patches
@ 2008-07-01 14:16 Rajendra Nayak
2008-07-02 13:11 ` Peter 'p2' De Schrijver
` (4 more replies)
0 siblings, 5 replies; 38+ messages in thread
From: Rajendra Nayak @ 2008-07-01 14:16 UTC (permalink / raw)
To: linux-omap
Hi,
The following patches define and enable all of the below mentioned C states for OMAP3.
These are tested with a minimal kernel config on OMAP3430sdp as most drivers today don't have context save/restore in place and
some even lack aggresive clock handling.
These apply on top of the workaround patch set submitted by Jouni.
([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.)
The following is neccessay even with a minimal config to achieve OFF.
$ echo 1 > /sys/power/sleep_while_idle
$ echo 1 > /sys/power/clocks_off_while_idle
The following C states are defined
C0 - System executing code
C1 - MPU WFI + Core active
C2 - MPU CSWR + Core active
C3 - MPU OFF + Core active
C4 - MPU CSWR + Core CSWR
C5 - MPU OFF + Core CSWR
C6 - MPU OFF + Core OFF
regards,
Rajendra
^ permalink raw reply [flat|nested] 38+ messages in thread* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-01 14:16 [PATCH 00/11] OMAP3 CPUidle patches Rajendra Nayak @ 2008-07-02 13:11 ` Peter 'p2' De Schrijver 2008-07-02 13:37 ` Rajendra Nayak 2008-07-03 5:57 ` Högander Jouni ` (3 subsequent siblings) 4 siblings, 1 reply; 38+ messages in thread From: Peter 'p2' De Schrijver @ 2008-07-02 13:11 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap [-- Attachment #1: Type: text/plain, Size: 1259 bytes --] Hi Rajendra, On Tue, Jul 01, 2008 at 07:46:01PM +0530, ext Rajendra Nayak wrote: > Hi, > > The following patches define and enable all of the below mentioned C states for OMAP3. > These are tested with a minimal kernel config on OMAP3430sdp as most drivers today don't have context save/restore in place and > some even lack aggresive clock handling. > These apply on top of the workaround patch set submitted by Jouni. > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > The following is neccessay even with a minimal config to achieve OFF. > $ echo 1 > /sys/power/sleep_while_idle > $ echo 1 > /sys/power/clocks_off_while_idle > > The following C states are defined > C0 - System executing code > C1 - MPU WFI + Core active > C2 - MPU CSWR + Core active > C3 - MPU OFF + Core active > C4 - MPU CSWR + Core CSWR > C5 - MPU OFF + Core CSWR > C6 - MPU OFF + Core OFF I don't see the core domain going to off state. On VDD1 I measured 52uA as the lowest consumption, VDD2 stays at 400uA. Maybe there is still a problem in my config file ? I disabled ethernet but I do use NOR flash to store the rootfs, so MTD needs to be enabled. Is that a problem ? Thanks, Peter. PS: config file in attachement -- goa is a state of mind [-- Attachment #2: .config --] [-- Type: text/plain, Size: 24557 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc8-omap1 # Wed Jul 2 15:53:44 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0xffff0000 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # 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_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 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_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y # CONFIG_ARCH_MSM7X00A is not set # # TI OMAP Implementations # CONFIG_ARCH_OMAP_OTG=y # CONFIG_ARCH_OMAP1 is not set # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_TESTING=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y # CONFIG_OMAP_COMPONENT_VERSION is not set # CONFIG_OMAP_GPIO_SWITCH is not set CONFIG_OMAP_MUX=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_OMAP_MUX_WARNINGS=y # CONFIG_OMAP_MCBSP is not set # CONFIG_OMAP_MMU_FWK is not set # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y CONFIG_OMAP_LL_DEBUG_UART1=y # CONFIG_OMAP_LL_DEBUG_UART2 is not set # CONFIG_OMAP_LL_DEBUG_UART3 is not set CONFIG_OMAP_SERIAL_WAKE=y CONFIG_ARCH_OMAP34XX=y CONFIG_ARCH_OMAP3430=y # # OMAP Board Type # # CONFIG_MACH_OMAP_LDP is not set CONFIG_MACH_OMAP_3430SDP=y # CONFIG_MACH_OMAP3EVM is not set # CONFIG_MACH_OMAP3_BEAGLE is not set # # Boot options # # # Power management # # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_32v6K=y CONFIG_CPU_V7=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y CONFIG_CPU_PABRT_IFAR=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_THUMB=y # CONFIG_ARM_THUMBEE 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_HAS_TLS_REG=y # CONFIG_OUTER_CACHE is not set # # Bus support # # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCCARD is not set # # Kernel Features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y CONFIG_OABI_COMPAT=y # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y # CONFIG_LEDS is not set CONFIG_ALIGNMENT_TRAP=y # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8" # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set # # CPUIdle # # # CPU idle PM support # CONFIG_CPU_IDLE=y # # Governors # # CONFIG_CPU_IDLE_GOV_LADDER is not set CONFIG_CPU_IDLE_GOV_MENU=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Floating point emulation # # # At least one emulation must be selected # # CONFIG_FPE_NWFPE is not set # CONFIG_FPE_FASTFPE is not set # CONFIG_VFP is not set # # Userspace binary formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y # CONFIG_APM_EMULATION is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y 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 is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES 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_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_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # 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_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_SCHED is not set # # 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 # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set CONFIG_MTD_CONCAT=y CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_REDBOOT_PARTS is not set CONFIG_MTD_CMDLINE_PARTS=y # CONFIG_MTD_AFS_PARTS is not set # CONFIG_MTD_AR7_PARTS is not set # # User Modules And Translation Layers # CONFIG_MTD_CHAR=y 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_MTD_OOPS 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 is not set # CONFIG_MTD_CFI_STAA is not set CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_RAM is not set # 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 is not set # CONFIG_MTD_ARM_INTEGRATOR is not set CONFIG_MTD_OMAP_NOR=y # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_NAND is not set CONFIG_MTD_ONENAND=y CONFIG_MTD_ONENAND_VERIFY_WRITE=y # CONFIG_MTD_ONENAND_GENERIC is not set CONFIG_MTD_ONENAND_OMAP2=y # CONFIG_MTD_ONENAND_OTP is not set # CONFIG_MTD_ONENAND_2X_PROGRAM is not set # CONFIG_MTD_ONENAND_SIM is not set # # UBI - Unsorted block images # # CONFIG_MTD_UBI is not set # CONFIG_PARPORT is not set # CONFIG_BLK_DEV is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_ATA is not set # CONFIG_MD is not set # CONFIG_NETDEVICES 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 # # 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_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=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 # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_NVRAM 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_CHARDEV=y # # I2C Hardware Bus support # # CONFIG_I2C_GPIO is not set # CONFIG_I2C_OCORES is not set CONFIG_I2C_OMAP=y # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_PCA_PLATFORM is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_ISP1301_OMAP is not set # CONFIG_TPS65010 is not set # CONFIG_SENSORS_TLV320AIC23 is not set CONFIG_TWL4030_CORE=y CONFIG_TWL4030_GPIO=y # CONFIG_TWL4030_MADC is not set CONFIG_TWL4030_USB=y CONFIG_TWL4030_USB_HS_ULPI=y # CONFIG_TWL4030_PWRBUTTON is not set # CONFIG_TWL4030_POWEROFF is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_LP5521 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set CONFIG_HAVE_GPIO_LIB=y # # GPIO Support # # CONFIG_DEBUG_GPIO is not set # # I2C GPIO expanders: # # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # # SPI GPIO expanders: # # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set # CONFIG_WATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # CONFIG_MFD_ASIC3 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # CONFIG_HID_SUPPORT is not set # CONFIG_USB_SUPPORT is not set # CONFIG_MMC is not set # CONFIG_NEW_LEDS is not set CONFIG_RTC_LIB=y # CONFIG_RTC_CLASS is not set # CONFIG_UIO is not set # # CBUS support # # CONFIG_CBUS is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_XFS_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS 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_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_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=y # CONFIG_JFFS2_FS_WBUF_VERIFY is not set # CONFIG_JFFS2_SUMMARY is not set # CONFIG_JFFS2_FS_XATTR is not set # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_ZLIB=y # CONFIG_JFFS2_LZO is not set CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=y # CONFIG_NFSD is not set CONFIG_ROOT_NFS=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y # CONFIG_SUNRPC_BIND34 is not set CONFIG_RPCSEC_GSS_KRB5=y # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_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 # # 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 is not set # CONFIG_SYSV68_PARTITION 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_UTF8 is not set # CONFIG_DLM is not set # # Kernel hacking # # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_SAMPLES is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_LL is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_MANAGER=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_TEST 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=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=m # CONFIG_CRYPTO_LRW is not set CONFIG_CRYPTO_PCBC=m # CONFIG_CRYPTO_XTS is not set # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_XCBC is not set # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # 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=y # 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 is not set # CONFIG_CRYPTO_LZO is not set CONFIG_CRYPTO_HW=y # # Library routines # CONFIG_BITREVERSE=y # CONFIG_GENERIC_FIND_FIRST_BIT is not set # CONFIG_GENERIC_FIND_NEXT_BIT is not set CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-02 13:11 ` Peter 'p2' De Schrijver @ 2008-07-02 13:37 ` Rajendra Nayak 2008-07-02 15:42 ` Peter 'p2' De Schrijver 0 siblings, 1 reply; 38+ messages in thread From: Rajendra Nayak @ 2008-07-02 13:37 UTC (permalink / raw) To: 'Peter 'p2' De Schrijver'; +Cc: linux-omap > -----Original Message----- > From: Peter 'p2' De Schrijver [mailto:peter.de-schrijver@nokia.com] > Sent: Wednesday, July 02, 2008 6:41 PM > To: ext Rajendra Nayak > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches > > Hi Rajendra, > > On Tue, Jul 01, 2008 at 07:46:01PM +0530, ext Rajendra Nayak wrote: > > Hi, > > > > The following patches define and enable all of the below > mentioned C states for OMAP3. > > These are tested with a minimal kernel config on > OMAP3430sdp as most drivers today don't have context > save/restore in place and > > some even lack aggresive clock handling. > > These apply on top of the workaround patch set submitted by Jouni. > > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > > > The following is neccessay even with a minimal config to > achieve OFF. > > $ echo 1 > /sys/power/sleep_while_idle > > $ echo 1 > /sys/power/clocks_off_while_idle > > > > The following C states are defined > > C0 - System executing code > > C1 - MPU WFI + Core active > > C2 - MPU CSWR + Core active > > C3 - MPU OFF + Core active > > C4 - MPU CSWR + Core CSWR > > C5 - MPU OFF + Core CSWR > > C6 - MPU OFF + Core OFF > > I don't see the core domain going to off state. On VDD1 I > measured 52uA > as the lowest consumption, VDD2 stays at 400uA. Maybe there is still a > problem in my config file ? I disabled ethernet but I do use NOR flash > to store the rootfs, so MTD needs to be enabled. Is that a problem ? Not sure, but you can try with my .config while I try with yours. I was doing some more testing today, and I saw a hang after a while of idle activity with OFF being attempted multiple times. Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying to clear MPU_IRQSTATUS. Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. here is the .config I use # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc8-omap1 # Tue Jul 1 16:50:36 2008 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0xffff0000 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # 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_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 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_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y # CONFIG_ARCH_MSM7X00A is not set # # TI OMAP Implementations # CONFIG_ARCH_OMAP_OTG=y # CONFIG_ARCH_OMAP1 is not set # CONFIG_ARCH_OMAP2 is not set CONFIG_ARCH_OMAP3=y # # OMAP Feature Selections # # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set CONFIG_OMAP_SMARTREFLEX=y CONFIG_OMAP_SMARTREFLEX_TESTING=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_BOOT_TAG=y CONFIG_OMAP_BOOT_REASON=y # CONFIG_OMAP_COMPONENT_VERSION is not set # CONFIG_OMAP_GPIO_SWITCH is not set CONFIG_OMAP_MUX=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_OMAP_MUX_WARNINGS=y # CONFIG_OMAP_MCBSP is not set # CONFIG_OMAP_MMU_FWK is not set # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y CONFIG_OMAP_LL_DEBUG_UART1=y # CONFIG_OMAP_LL_DEBUG_UART2 is not set # CONFIG_OMAP_LL_DEBUG_UART3 is not set CONFIG_OMAP_SERIAL_WAKE=y CONFIG_ARCH_OMAP34XX=y CONFIG_ARCH_OMAP3430=y # # OMAP Board Type # # CONFIG_MACH_OMAP_LDP is not set CONFIG_MACH_OMAP_3430SDP=y # CONFIG_MACH_OMAP3EVM is not set # CONFIG_MACH_OMAP3_BEAGLE is not set # # Boot options # # # Power management # # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_32v6K=y CONFIG_CPU_V7=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y CONFIG_CPU_PABRT_IFAR=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_THUMB=y # CONFIG_ARM_THUMBEE 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_HAS_TLS_REG=y # CONFIG_OUTER_CACHE is not set # # Bus support # # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCCARD is not set # # Kernel Features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_PREEMPT is not set CONFIG_HZ=128 CONFIG_AEABI=y CONFIG_OABI_COMPAT=y # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y # CONFIG_LEDS is not set CONFIG_ALIGNMENT_TRAP=y # # Boot options # CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="root=/dev/nfs nfsroot=192.168.0.1:/home/user/buildroot ip=192.168.0.2:192.168.0.1:192.168.0.1:255.255.255.0:tgt:eth0:off rw console=ttyS2,115200n8" # CONFIG_XIP_KERNEL is not set # CONFIG_KEXEC is not set # # CPUIdle # # # CPU idle PM support # CONFIG_CPU_IDLE=y # # Governors # # CONFIG_CPU_IDLE_GOV_LADDER is not set CONFIG_CPU_IDLE_GOV_MENU=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Floating point emulation # # # At least one emulation must be selected # # CONFIG_FPE_NWFPE is not set # CONFIG_FPE_FASTFPE is not set # CONFIG_VFP is not set # # Userspace binary formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y # CONFIG_APM_EMULATION is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y 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 is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES 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_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_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # 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_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_SCHED is not set # # 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 # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set # CONFIG_BLK_DEV is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_ATA is not set # CONFIG_MD is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_VETH is not set # CONFIG_PHYLIB is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_AX88796 is not set CONFIG_SMC91X=y # CONFIG_DM9000 is not set # CONFIG_SMC911X is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set # CONFIG_B44 is not set CONFIG_NETDEV_1000=y # CONFIG_E1000E_ENABLED is not set CONFIG_NETDEV_10000=y # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # CONFIG_IWLWIFI_LEDS is not set # CONFIG_WAN is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER 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 # # 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_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=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 # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y # CONFIG_NVRAM 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_CHARDEV=y # # I2C Hardware Bus support # # CONFIG_I2C_GPIO is not set # CONFIG_I2C_OCORES is not set CONFIG_I2C_OMAP=y # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_PCA_PLATFORM is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_ISP1301_OMAP is not set # CONFIG_TPS65010 is not set # CONFIG_SENSORS_TLV320AIC23 is not set CONFIG_TWL4030_CORE=y CONFIG_TWL4030_GPIO=y # CONFIG_TWL4030_MADC is not set CONFIG_TWL4030_USB=y CONFIG_TWL4030_USB_HS_ULPI=y # CONFIG_TWL4030_PWRBUTTON is not set # CONFIG_TWL4030_POWEROFF is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_LP5521 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set CONFIG_HAVE_GPIO_LIB=y # # GPIO Support # # CONFIG_DEBUG_GPIO is not set # # I2C GPIO expanders: # # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set # # SPI GPIO expanders: # # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set # CONFIG_WATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # CONFIG_MFD_ASIC3 is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # CONFIG_HID_SUPPORT is not set # CONFIG_USB_SUPPORT is not set # CONFIG_MMC is not set # CONFIG_NEW_LEDS is not set CONFIG_RTC_LIB=y # CONFIG_RTC_CLASS is not set # CONFIG_UIO is not set # # CBUS support # # CONFIG_CBUS is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_XFS_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS 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_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_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_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=y # CONFIG_NFSD is not set CONFIG_ROOT_NFS=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y # CONFIG_SUNRPC_BIND34 is not set CONFIG_RPCSEC_GSS_KRB5=y # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_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 # # 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 is not set # CONFIG_SYSV68_PARTITION 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_UTF8 is not set # CONFIG_DLM is not set # # Kernel hacking # # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y CONFIG_SCHED_DEBUG=y # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_SAMPLES is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_ERRORS is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_LL is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_MANAGER=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_TEST 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=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=m # CONFIG_CRYPTO_LRW is not set CONFIG_CRYPTO_PCBC=m # CONFIG_CRYPTO_XTS is not set # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_XCBC is not set # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # 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=y # 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 is not set # CONFIG_CRYPTO_LZO is not set CONFIG_CRYPTO_HW=y # # Library routines # CONFIG_BITREVERSE=y # CONFIG_GENERIC_FIND_FIRST_BIT is not set # CONFIG_GENERIC_FIND_NEXT_BIT is not set CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y > > Thanks, > > Peter. > > PS: config file in attachement > > -- > goa is a state of mind > ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-02 13:37 ` Rajendra Nayak @ 2008-07-02 15:42 ` Peter 'p2' De Schrijver 2008-07-03 8:39 ` Rajendra Nayak 0 siblings, 1 reply; 38+ messages in thread From: Peter 'p2' De Schrijver @ 2008-07-02 15:42 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap Hi Rajendra, > > Not sure, but you can try with my .config while I try with yours. > I was doing some more testing today, and I saw a hang after a while of > idle activity with OFF being attempted multiple times. > Using lauterbach showed me it being stuck up in prcm_interrupt_handler trying > to clear MPU_IRQSTATUS. > Looks like in the PRCM interrupt handler somehow PM_WKST1_CORE is not cleared > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. > Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the first wakeup, off mode is never reached again. Cheers, Peter. ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-02 15:42 ` Peter 'p2' De Schrijver @ 2008-07-03 8:39 ` Rajendra Nayak 2008-07-03 12:44 ` Peter 'p2' De Schrijver 2008-07-04 7:26 ` Högander Jouni 0 siblings, 2 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-07-03 8:39 UTC (permalink / raw) To: 'Peter 'p2' De Schrijver'; +Cc: linux-omap > -----Original Message----- > From: Peter 'p2' De Schrijver [mailto:peter.de-schrijver@nokia.com] > Sent: Wednesday, July 02, 2008 9:13 PM > To: ext Rajendra Nayak > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches > > Hi Rajendra, > > > > > Not sure, but you can try with my .config while I try with yours. > > I was doing some more testing today, and I saw a hang after > a while of > > idle activity with OFF being attempted multiple times. > > Using lauterbach showed me it being stuck up in > prcm_interrupt_handler trying > > to clear MPU_IRQSTATUS. > > Looks like in the PRCM interrupt handler somehow > PM_WKST1_CORE is not cleared > > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. > > > > Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. > Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the > first wakeup, off mode is never reached again. Do you see a hang? or OFF is never achieved? Can you try with the latest fixes that I posted. > > Cheers, > > Peter. > ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-03 8:39 ` Rajendra Nayak @ 2008-07-03 12:44 ` Peter 'p2' De Schrijver 2008-07-04 7:26 ` Högander Jouni 1 sibling, 0 replies; 38+ messages in thread From: Peter 'p2' De Schrijver @ 2008-07-03 12:44 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap On Thu, Jul 03, 2008 at 02:09:42PM +0530, ext Rajendra Nayak wrote: > > -----Original Message----- > > From: Peter 'p2' De Schrijver [mailto:peter.de-schrijver@nokia.com] > > Sent: Wednesday, July 02, 2008 9:13 PM > > To: ext Rajendra Nayak > > Cc: linux-omap@vger.kernel.org > > Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches > > > > Hi Rajendra, > > > > > > > > Not sure, but you can try with my .config while I try with yours. > > > I was doing some more testing today, and I saw a hang after > > a while of > > > idle activity with OFF being attempted multiple times. > > > Using lauterbach showed me it being stuck up in > > prcm_interrupt_handler trying > > > to clear MPU_IRQSTATUS. > > > Looks like in the PRCM interrupt handler somehow > > PM_WKST1_CORE is not cleared > > > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. > > > > > > > Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. > > Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the > > first wakeup, off mode is never reached again. > > Do you see a hang? or OFF is never achieved? No hang, but OFF is never achieved after the first UART wakeup. > Can you try with the latest fixes that I posted. > Doesn't change anything. Cheers, Peter. -- goa is a state of mind ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-03 8:39 ` Rajendra Nayak 2008-07-03 12:44 ` Peter 'p2' De Schrijver @ 2008-07-04 7:26 ` Högander Jouni 2008-07-04 9:32 ` Högander Jouni 1 sibling, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-07-04 7:26 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: 'Peter 'p2' De Schrijver', linux-omap Hi Rajendra, "ext Rajendra Nayak" <rnayak@ti.com> writes: >> -----Original Message----- >> From: Peter 'p2' De Schrijver [mailto:peter.de-schrijver@nokia.com] >> Sent: Wednesday, July 02, 2008 9:13 PM >> To: ext Rajendra Nayak >> Cc: linux-omap@vger.kernel.org >> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches >> >> Hi Rajendra, >> >> > >> > Not sure, but you can try with my .config while I try with yours. >> > I was doing some more testing today, and I saw a hang after >> a while of >> > idle activity with OFF being attempted multiple times. >> > Using lauterbach showed me it being stuck up in >> prcm_interrupt_handler trying >> > to clear MPU_IRQSTATUS. >> > Looks like in the PRCM interrupt handler somehow >> PM_WKST1_CORE is not cleared >> > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. >> > >> >> Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. >> Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the >> first wakeup, off mode is never reached again. > > Do you see a hang? or OFF is never achieved? > Can you try with the latest fixes that I posted. As it seems to be hard to get similiar results with these patches, could you please send me your uImage? > >> >> Cheers, >> >> Peter. >> > > -- > 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 > > -- Jouni Högander -- 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] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 7:26 ` Högander Jouni @ 2008-07-04 9:32 ` Högander Jouni 2008-07-04 9:45 ` Koen Kooi ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Högander Jouni @ 2008-07-04 9:32 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: 'Peter 'p2' De Schrijver', linux-omap Let's continue this discussion in here to make sure that everybody sees it. ext Högander Jouni <jouni.hogander@nokia.com> writes: > Hi Rajendra, > > "ext Rajendra Nayak" <rnayak@ti.com> writes: > >>> -----Original Message----- >>> From: Peter 'p2' De Schrijver [mailto:peter.de-schrijver@nokia.com] >>> Sent: Wednesday, July 02, 2008 9:13 PM >>> To: ext Rajendra Nayak >>> Cc: linux-omap@vger.kernel.org >>> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches >>> >>> Hi Rajendra, >>> >>> > >>> > Not sure, but you can try with my .config while I try with yours. >>> > I was doing some more testing today, and I saw a hang after >>> a while of >>> > idle activity with OFF being attempted multiple times. >>> > Using lauterbach showed me it being stuck up in >>> prcm_interrupt_handler trying >>> > to clear MPU_IRQSTATUS. >>> > Looks like in the PRCM interrupt handler somehow >>> PM_WKST1_CORE is not cleared >>> > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. >>> > >>> >>> Ok. I disabled OneNAND support and now I get off mode on VDD2 as well. >>> Consumption on VDD1 is 4uA and 32uA on VDD2. Unfortunately after the >>> first wakeup, off mode is never reached again. >> >> Do you see a hang? or OFF is never achieved? >> Can you try with the latest fixes that I posted. > > As it seems to be hard to get similiar results with these patches, > could you please send me your uImage? So Rajendra sent his uImage and it works quite ok what comes to off mode on my sdp board. I still see problems with serial console (slow) and on boot I need to generate manually interrupts to get it to boot. Otherwise board hangs at this point: eth0: link up Sending DHCP requests ., OK IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 IP-Config: Complete: device=eth0, addr=192.168.2.101, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= Looking up port of RPC 100003/2 on 172.22.146.197 Looking up port of RPC 100005/1 on 172.22.146.197 VFS: Mounted root (nfs filesystem). Freeing init memory: 108K Rajendra, are you still using .config file you sent to me? Are all the changes in your tree available in l-o list. > >> >>> >>> Cheers, >>> >>> Peter. >>> >> >> -- >> 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 >> >> > > -- > Jouni Högander > > -- > 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 > > -- Jouni Högander -- 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] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 9:32 ` Högander Jouni @ 2008-07-04 9:45 ` Koen Kooi 2008-07-04 9:45 ` Rajendra Nayak 2008-07-04 11:05 ` Peter 'p2' De Schrijver 2 siblings, 0 replies; 38+ messages in thread From: Koen Kooi @ 2008-07-04 9:45 UTC (permalink / raw) To: Högander Jouni Cc: ext Rajendra Nayak, 'Peter 'p2' De Schrijver', linux-omap [-- Attachment #1: Type: text/plain, Size: 275 bytes --] Op 4 jul 2008, om 11:32 heeft Högander Jouni het volgende geschreven: > Rajendra, are you still using .config file you sent to me? Are all the > changes in your tree available in l-o list. IK_CONFIG is such a timesaver in this kind of situations :) regards, Koen [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 186 bytes --] ^ permalink raw reply [flat|nested] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 9:32 ` Högander Jouni 2008-07-04 9:45 ` Koen Kooi @ 2008-07-04 9:45 ` Rajendra Nayak 2008-07-04 9:55 ` Högander Jouni ` (2 more replies) 2008-07-04 11:05 ` Peter 'p2' De Schrijver 2 siblings, 3 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-07-04 9:45 UTC (permalink / raw) To: '"Högander" Jouni' Cc: 'Peter 'p2' De Schrijver', linux-omap > -----Original Message----- > From: "Högander" Jouni [mailto:jouni.hogander@nokia.com] > Sent: Friday, July 04, 2008 3:02 PM > To: ext Rajendra Nayak > Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org > Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches > > Let's continue this discussion in here to make sure that everybody > sees it. > > ext Högander Jouni <jouni.hogander@nokia.com> writes: > > > Hi Rajendra, > > > > "ext Rajendra Nayak" <rnayak@ti.com> writes: > > > >>> -----Original Message----- > >>> From: Peter 'p2' De Schrijver > [mailto:peter.de-schrijver@nokia.com] > >>> Sent: Wednesday, July 02, 2008 9:13 PM > >>> To: ext Rajendra Nayak > >>> Cc: linux-omap@vger.kernel.org > >>> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches > >>> > >>> Hi Rajendra, > >>> > >>> > > >>> > Not sure, but you can try with my .config while I try > with yours. > >>> > I was doing some more testing today, and I saw a hang after > >>> a while of > >>> > idle activity with OFF being attempted multiple times. > >>> > Using lauterbach showed me it being stuck up in > >>> prcm_interrupt_handler trying > >>> > to clear MPU_IRQSTATUS. > >>> > Looks like in the PRCM interrupt handler somehow > >>> PM_WKST1_CORE is not cleared > >>> > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. > >>> > > >>> > >>> Ok. I disabled OneNAND support and now I get off mode on > VDD2 as well. > >>> Consumption on VDD1 is 4uA and 32uA on VDD2. > Unfortunately after the > >>> first wakeup, off mode is never reached again. > >> > >> Do you see a hang? or OFF is never achieved? > >> Can you try with the latest fixes that I posted. > > > > As it seems to be hard to get similiar results with these patches, > > could you please send me your uImage? > > So Rajendra sent his uImage and it works quite ok what comes to off > mode on my sdp board. I still see problems with serial console (slow) > and on boot I need to generate manually interrupts to get it to > boot. Otherwise board hangs at this point: Yes, I noticed this as well. It takes quite long to bootup if you don't generate UART interrupts. After bootup once RET/OFF is hit, it takes a few hits to come out of it as IO wakeup is missing. > > eth0: link up > Sending DHCP requests ., OK > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 > IP-Config: Complete: > device=eth0, addr=192.168.2.101, mask=255.255.255.0, > gw=192.168.2.1, > host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), > bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= > Looking up port of RPC 100003/2 on 172.22.146.197 > Looking up port of RPC 100005/1 on 172.22.146.197 > VFS: Mounted root (nfs filesystem). > Freeing init memory: 108K > > Rajendra, are you still using .config file you sent to me? Are all the > changes in your tree available in l-o list. Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm to see what states are selected by the menu gov. We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or never attempted altogether. > > > > >> > >>> > >>> Cheers, > >>> > >>> Peter. > >>> > >> > >> -- > >> 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 > >> > >> > > > > -- > > Jouni Högander > > > > -- > > 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 > > > > > > -- > Jouni Högander > > -- 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] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 9:45 ` Rajendra Nayak @ 2008-07-04 9:55 ` Högander Jouni 2008-07-04 11:08 ` Högander Jouni 2008-07-07 9:38 ` Kalle Jokiniemi 2 siblings, 0 replies; 38+ messages in thread From: Högander Jouni @ 2008-07-04 9:55 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: 'Peter 'p2' De Schrijver', linux-omap "ext Rajendra Nayak" <rnayak@ti.com> writes: >> -----Original Message----- >> From: "Högander" Jouni [mailto:jouni.hogander@nokia.com] >> Sent: Friday, July 04, 2008 3:02 PM >> To: ext Rajendra Nayak >> Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org >> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches >> >> Let's continue this discussion in here to make sure that everybody >> sees it. >> >> ext Högander Jouni <jouni.hogander@nokia.com> writes: >> >> > Hi Rajendra, >> > >> > "ext Rajendra Nayak" <rnayak@ti.com> writes: >> > >> >>> -----Original Message----- >> >>> From: Peter 'p2' De Schrijver >> [mailto:peter.de-schrijver@nokia.com] >> >>> Sent: Wednesday, July 02, 2008 9:13 PM >> >>> To: ext Rajendra Nayak >> >>> Cc: linux-omap@vger.kernel.org >> >>> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches >> >>> >> >>> Hi Rajendra, >> >>> >> >>> > >> >>> > Not sure, but you can try with my .config while I try >> with yours. >> >>> > I was doing some more testing today, and I saw a hang after >> >>> a while of >> >>> > idle activity with OFF being attempted multiple times. >> >>> > Using lauterbach showed me it being stuck up in >> >>> prcm_interrupt_handler trying >> >>> > to clear MPU_IRQSTATUS. >> >>> > Looks like in the PRCM interrupt handler somehow >> >>> PM_WKST1_CORE is not cleared >> >>> > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. >> >>> > >> >>> >> >>> Ok. I disabled OneNAND support and now I get off mode on >> VDD2 as well. >> >>> Consumption on VDD1 is 4uA and 32uA on VDD2. >> Unfortunately after the >> >>> first wakeup, off mode is never reached again. >> >> >> >> Do you see a hang? or OFF is never achieved? >> >> Can you try with the latest fixes that I posted. >> > >> > As it seems to be hard to get similiar results with these patches, >> > could you please send me your uImage? >> >> So Rajendra sent his uImage and it works quite ok what comes to off >> mode on my sdp board. I still see problems with serial console (slow) >> and on boot I need to generate manually interrupts to get it to >> boot. Otherwise board hangs at this point: > > Yes, I noticed this as well. It takes quite long to bootup if you don't > generate UART interrupts. > After bootup once RET/OFF is hit, it takes a few hits to come out of it > as IO wakeup is missing. Can you try to disable C2 state. I noticed that this state is used all the time at the point on boot where board hangs. I tried to disable and after this boot worked ok. With my image I couldn't achieve off state. > >> >> eth0: link up >> Sending DHCP requests ., OK >> IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 >> IP-Config: Complete: >> device=eth0, addr=192.168.2.101, mask=255.255.255.0, >> gw=192.168.2.1, >> host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), >> bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= >> Looking up port of RPC 100003/2 on 172.22.146.197 >> Looking up port of RPC 100005/1 on 172.22.146.197 >> VFS: Mounted root (nfs filesystem). >> Freeing init memory: 108K >> >> Rajendra, are you still using .config file you sent to me? Are all the >> changes in your tree available in l-o list. > > Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. > To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm > to see what states are selected by the menu gov. > We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or > never attempted altogether. Ok, will send my results soon. -- Jouni Högander -- 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] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 9:45 ` Rajendra Nayak 2008-07-04 9:55 ` Högander Jouni @ 2008-07-04 11:08 ` Högander Jouni 2008-07-07 9:38 ` Kalle Jokiniemi 2 siblings, 0 replies; 38+ messages in thread From: Högander Jouni @ 2008-07-04 11:08 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: 'Peter 'p2' De Schrijver', linux-omap "ext Rajendra Nayak" <rnayak@ti.com> writes: >> -----Original Message----- >> From: "Högander" Jouni [mailto:jouni.hogander@nokia.com] >> Sent: Friday, July 04, 2008 3:02 PM >> To: ext Rajendra Nayak >> Cc: 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org >> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches >> >> Let's continue this discussion in here to make sure that everybody >> sees it. >> >> ext Högander Jouni <jouni.hogander@nokia.com> writes: >> >> > Hi Rajendra, >> > >> > "ext Rajendra Nayak" <rnayak@ti.com> writes: >> > >> >>> -----Original Message----- >> >>> From: Peter 'p2' De Schrijver >> [mailto:peter.de-schrijver@nokia.com] >> >>> Sent: Wednesday, July 02, 2008 9:13 PM >> >>> To: ext Rajendra Nayak >> >>> Cc: linux-omap@vger.kernel.org >> >>> Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches >> >>> >> >>> Hi Rajendra, >> >>> >> >>> > >> >>> > Not sure, but you can try with my .config while I try >> with yours. >> >>> > I was doing some more testing today, and I saw a hang after >> >>> a while of >> >>> > idle activity with OFF being attempted multiple times. >> >>> > Using lauterbach showed me it being stuck up in >> >>> prcm_interrupt_handler trying >> >>> > to clear MPU_IRQSTATUS. >> >>> > Looks like in the PRCM interrupt handler somehow >> >>> PM_WKST1_CORE is not cleared >> >>> > (I see it set to 0x2000) and hence MPU_IRQSTATUS fails to clear. >> >>> > >> >>> >> >>> Ok. I disabled OneNAND support and now I get off mode on >> VDD2 as well. >> >>> Consumption on VDD1 is 4uA and 32uA on VDD2. >> Unfortunately after the >> >>> first wakeup, off mode is never reached again. >> >> >> >> Do you see a hang? or OFF is never achieved? >> >> Can you try with the latest fixes that I posted. >> > >> > As it seems to be hard to get similiar results with these patches, >> > could you please send me your uImage? >> >> So Rajendra sent his uImage and it works quite ok what comes to off >> mode on my sdp board. I still see problems with serial console (slow) >> and on boot I need to generate manually interrupts to get it to >> boot. Otherwise board hangs at this point: > > Yes, I noticed this as well. It takes quite long to bootup if you don't > generate UART interrupts. > After bootup once RET/OFF is hit, it takes a few hits to come out of it > as IO wakeup is missing. > >> >> eth0: link up >> Sending DHCP requests ., OK >> IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 >> IP-Config: Complete: >> device=eth0, addr=192.168.2.101, mask=255.255.255.0, >> gw=192.168.2.1, >> host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), >> bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= >> Looking up port of RPC 100003/2 on 172.22.146.197 >> Looking up port of RPC 100005/1 on 172.22.146.197 >> VFS: Mounted root (nfs filesystem). >> Freeing init memory: 108K >> >> Rajendra, are you still using .config file you sent to me? Are all the >> changes in your tree available in l-o list. > > Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. > To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm > to see what states are selected by the menu gov. > We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or > never attempted altogether. It seems that I get off state also with my own binary: diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 6440515..545ce99 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -447,7 +447,9 @@ static int omap3_enter_idle(struct cpuidle_device *dev, if (cx->type > OMAP3_STATE_C1) sched_clock_idle_sleep_event(); /* about to enter deep idle */ - + if (cx->type == OMAP3_STATE_C6) + printk(KERN_ERR"Trying OMAP3_STATE_C6\n"); + mpu_pd = pwrdm_lookup("mpu_pwrdm"); core_pd = pwrdm_lookup("core_pwrdm"); per_pd = pwrdm_lookup("per_pwrdm"); @@ -521,6 +523,15 @@ static int omap3_enter_idle(struct cpuidle_device *dev, omap2_gpio_resume_after_retention(); } + if (!pwrdm_read_prev_pwrst(mpu_pd)) + printk("mpu off achieved\n"); + if (!pwrdm_read_prev_pwrst(core_pd)) + printk("core off achieved\n"); + if (!pwrdm_read_prev_pwrst(per_pd)) + printk("per off achieved\n"); + if (!pwrdm_read_prev_pwrst(neon_pd)) + printk("neon off achieved\n"); + And the output is this: Trying OMAP3_STATE_C6 mpu off achieved core off achieved per off achieved Neon is not printed as it is in off or ret all the time. Basically off state is achieved using Rajendras patches + config. I still see that hang on boot. I have feeling that it is related to other states than C6. I tried to disable all other states than C0 and C6 by setting valid bit to 0. After this boot works ok, but C6 state is never tried. Any idea why? There is still some occasional hangs. Seems to be related to wakeup. > >> >> > >> >> >> >>> >> >>> Cheers, >> >>> >> >>> Peter. >> >>> >> >> >> >> -- >> >> 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 >> >> >> >> >> > >> > -- >> > Jouni Högander >> > >> > -- >> > 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 >> > >> > >> >> -- >> Jouni Högander >> >> > > > -- Jouni Högander -- 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 related [flat|nested] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 9:45 ` Rajendra Nayak 2008-07-04 9:55 ` Högander Jouni 2008-07-04 11:08 ` Högander Jouni @ 2008-07-07 9:38 ` Kalle Jokiniemi 2008-07-07 9:56 ` Högander Jouni 2 siblings, 1 reply; 38+ messages in thread From: Kalle Jokiniemi @ 2008-07-07 9:38 UTC (permalink / raw) To: ext Rajendra Nayak Cc: '"Högander" Jouni', 'Peter 'p2' De Schrijver', linux-omap On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote: ... > > ext Högander Jouni <jouni.hogander@nokia.com> writes: ... > > > > So Rajendra sent his uImage and it works quite ok what comes to off > > mode on my sdp board. I still see problems with serial console (slow) > > and on boot I need to generate manually interrupts to get it to > > boot. Otherwise board hangs at this point: > > Yes, I noticed this as well. It takes quite long to bootup if you don't > generate UART interrupts. > After bootup once RET/OFF is hit, it takes a few hits to come out of it > as IO wakeup is missing. Jouni had a theory that the ethernet device could cause this slowness trouble in the startup, so I investigated the matter a little further. By enabling the debug prints in the ethernet chip driver, diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index 776c81d..7d1eead 100644 --- a/drivers/net/smc91x.c +++ b/drivers/net/smc91x.c @@ -62,7 +62,7 @@ static const char version[] = /* Debugging level */ #ifndef SMC_DEBUG -#define SMC_DEBUG 0 +#define SMC_DEBUG 1 #endif I was able to see, that we get lots of RX overrun interrupts with cpu_idle, meaning that incoming stuff is not getting processed. By generating UART interrupts, I we probably can also catch more network RX interrupts and this helps the bootup go faster. With cpu_idle disabled, there were no RX overruns. I'll try to see if this can be fixed somehow. > > > > > eth0: link up > > Sending DHCP requests ., OK > > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 > > IP-Config: Complete: > > device=eth0, addr=192.168.2.101, mask=255.255.255.0, > > gw=192.168.2.1, > > host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), > > bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= > > Looking up port of RPC 100003/2 on 172.22.146.197 > > Looking up port of RPC 100005/1 on 172.22.146.197 > > VFS: Mounted root (nfs filesystem). > > Freeing init memory: 108K > > > > Rajendra, are you still using .config file you sent to me? Are all the > > changes in your tree available in l-o list. > > Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. > To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm > to see what states are selected by the menu gov. > We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or > never attempted altogether. My setup does not seem to go beyond C2 state, btw. So I'll need to debug that also a bit. The above-mentioned patches are applied. Br, Kalle ... -- 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 related [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-07 9:38 ` Kalle Jokiniemi @ 2008-07-07 9:56 ` Högander Jouni 2008-07-07 13:58 ` Premi, Sanjeev 0 siblings, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-07-07 9:56 UTC (permalink / raw) To: Kalle Jokiniemi Cc: ext Rajendra Nayak, 'Peter 'p2' De Schrijver', linux-omap Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com> writes: > On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote: > ... >> > ext Högander Jouni <jouni.hogander@nokia.com> writes: > > ... > >> > >> > So Rajendra sent his uImage and it works quite ok what comes to off >> > mode on my sdp board. I still see problems with serial console (slow) >> > and on boot I need to generate manually interrupts to get it to >> > boot. Otherwise board hangs at this point: >> >> Yes, I noticed this as well. It takes quite long to bootup if you don't >> generate UART interrupts. >> After bootup once RET/OFF is hit, it takes a few hits to come out of it >> as IO wakeup is missing. > > Jouni had a theory that the ethernet device could cause this slowness > trouble in the startup, so I investigated the matter a little further. > By enabling the debug prints in the ethernet chip driver, > > diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c > index 776c81d..7d1eead 100644 > --- a/drivers/net/smc91x.c > +++ b/drivers/net/smc91x.c > @@ -62,7 +62,7 @@ static const char version[] = > > /* Debugging level */ > #ifndef SMC_DEBUG > -#define SMC_DEBUG 0 > +#define SMC_DEBUG 1 > #endif > > > I was able to see, that we get lots of RX overrun interrupts with > cpu_idle, meaning that incoming stuff is not getting processed. By > generating UART interrupts, I we probably can also catch more network RX > interrupts and this helps the bootup go faster. With cpu_idle disabled, > there were no RX overruns. Your investigation supports this theory. Interrupt line from eth chip doesn't wake up mpu. I assume it is gpio line. Those are added to mpu wake-up events group, gpio wake-ups are enabled and mpu peripherals group wake-up event interrupt is enabled. I'm suspecting that this problem happens if state where mpu is in sleep state and core+per are awake is used. Any comments from TI people what might be wrong? > > I'll try to see if this can be fixed somehow. > >> >> > >> > eth0: link up >> > Sending DHCP requests ., OK >> > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 >> > IP-Config: Complete: >> > device=eth0, addr=192.168.2.101, mask=255.255.255.0, >> > gw=192.168.2.1, >> > host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), >> > bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= >> > Looking up port of RPC 100003/2 on 172.22.146.197 >> > Looking up port of RPC 100005/1 on 172.22.146.197 >> > VFS: Mounted root (nfs filesystem). >> > Freeing init memory: 108K >> > >> > Rajendra, are you still using .config file you sent to me? Are all the >> > changes in your tree available in l-o list. >> >> Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. >> To debug further, can you put a few prints in omap3_enter_idle and omap3_enter_idle_bm >> to see what states are selected by the menu gov. >> We will then know if CORE RET/OFF is attempted but not achieved due to some reason, or >> never attempted altogether. > > My setup does not seem to go beyond C2 state, btw. So I'll need to debug > that also a bit. The above-mentioned patches are applied. > > Br, Kalle > > > ... > > > -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-07 9:56 ` Högander Jouni @ 2008-07-07 13:58 ` Premi, Sanjeev 2008-07-07 22:25 ` Woodruff, Richard 0 siblings, 1 reply; 38+ messages in thread From: Premi, Sanjeev @ 2008-07-07 13:58 UTC (permalink / raw) To: Högander Jouni, Kalle Jokiniemi Cc: Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org I am still trying to find my way thru the codebase in GIT; but here is what I can suggest based on similar problem diagnosed (still under test) on the OMAP3EVM: 1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2 2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2 This needs to be done before entering (or leaving) deeper C-states. Hope this helps. Best regards, Sanjeev -----Original Message----- From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Högander Jouni Sent: Monday, July 07, 2008 3:27 PM To: Kalle Jokiniemi Cc: Nayak, Rajendra; 'Peter 'p2' De Schrijver'; linux-omap@vger.kernel.org Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com> writes: > On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote: > ... >> > ext Högander Jouni <jouni.hogander@nokia.com> writes: > > ... > >> > >> > So Rajendra sent his uImage and it works quite ok what comes to off >> > mode on my sdp board. I still see problems with serial console >> > (slow) and on boot I need to generate manually interrupts to get it >> > to boot. Otherwise board hangs at this point: >> >> Yes, I noticed this as well. It takes quite long to bootup if you >> don't generate UART interrupts. >> After bootup once RET/OFF is hit, it takes a few hits to come out of >> it as IO wakeup is missing. > > Jouni had a theory that the ethernet device could cause this slowness > trouble in the startup, so I investigated the matter a little further. > By enabling the debug prints in the ethernet chip driver, > > diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index > 776c81d..7d1eead 100644 > --- a/drivers/net/smc91x.c > +++ b/drivers/net/smc91x.c > @@ -62,7 +62,7 @@ static const char version[] = > > /* Debugging level */ > #ifndef SMC_DEBUG > -#define SMC_DEBUG 0 > +#define SMC_DEBUG 1 > #endif > > > I was able to see, that we get lots of RX overrun interrupts with > cpu_idle, meaning that incoming stuff is not getting processed. By > generating UART interrupts, I we probably can also catch more network > RX interrupts and this helps the bootup go faster. With cpu_idle > disabled, there were no RX overruns. Your investigation supports this theory. Interrupt line from eth chip doesn't wake up mpu. I assume it is gpio line. Those are added to mpu wake-up events group, gpio wake-ups are enabled and mpu peripherals group wake-up event interrupt is enabled. I'm suspecting that this problem happens if state where mpu is in sleep state and core+per are awake is used. Any comments from TI people what might be wrong? > > I'll try to see if this can be fixed somehow. > >> >> > >> > eth0: link up >> > Sending DHCP requests ., OK >> > IP-Config: Got DHCP answer from 0.0.0.0, my address is >> > 192.168.2.101 >> > IP-Config: Complete: >> > device=eth0, addr=192.168.2.101, mask=255.255.255.0, >> > gw=192.168.2.1, >> > host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), >> > bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= >> > Looking up port of RPC 100003/2 on 172.22.146.197 Looking up port >> > of RPC 100005/1 on 172.22.146.197 >> > VFS: Mounted root (nfs filesystem). >> > Freeing init memory: 108K >> > >> > Rajendra, are you still using .config file you sent to me? Are all >> > the changes in your tree available in l-o list. >> >> Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent. >> To debug further, can you put a few prints in omap3_enter_idle and >> omap3_enter_idle_bm to see what states are selected by the menu gov. >> We will then know if CORE RET/OFF is attempted but not achieved due >> to some reason, or never attempted altogether. > > My setup does not seem to go beyond C2 state, btw. So I'll need to > debug that also a bit. The above-mentioned patches are applied. > > Br, Kalle > > > ... > > > -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-07 13:58 ` Premi, Sanjeev @ 2008-07-07 22:25 ` Woodruff, Richard 2008-07-08 6:15 ` Högander Jouni 0 siblings, 1 reply; 38+ messages in thread From: Woodruff, Richard @ 2008-07-07 22:25 UTC (permalink / raw) To: Premi, Sanjeev, Högander Jouni, Kalle Jokiniemi Cc: Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org > I am still trying to find my way thru the codebase in GIT; but here is > what I can suggest based on similar problem diagnosed (still under > test) on the OMAP3EVM: > > 1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2 > 2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2 For sure save/restore of IRQENABLE is needed. Our Labrador board which has Ethernet on per-gpio would stop to function after an OFF mode transition with out this save and restore (using CDP reference code). I don't think STATUS is necessary. It’s a write 1 to clear register and should re-latch once there is data. As a side note I was noting that the SMC9211 etherchip actually may need a dvfs pre-post notifier. During DVFS spurious interrupt events cause the interface to disable interrupts on its own on some tests. Regards, Richard W. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-07 22:25 ` Woodruff, Richard @ 2008-07-08 6:15 ` Högander Jouni 2008-07-08 12:11 ` Woodruff, Richard 0 siblings, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-07-08 6:15 UTC (permalink / raw) To: ext Woodruff, Richard Cc: Premi, Sanjeev, Kalle Jokiniemi, Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org "ext Woodruff, Richard" <r-woodruff2@ti.com> writes: >> I am still trying to find my way thru the codebase in GIT; but here is >> what I can suggest based on similar problem diagnosed (still under >> test) on the OMAP3EVM: >> >> 1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2 >> 2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2 > > For sure save/restore of IRQENABLE is needed. Our Labrador board > which has Ethernet on per-gpio would stop to function after an OFF > mode transition with out this save and restore (using CDP reference > code). I think this is not related to OFF mode, because OFF state is not used on the boot. This problem seems to disappear when boot is done and C6 state is started to be used. Currently it seems to me that this problem exists if using states where mpu is in sleep state and core is active (C2, C3). This is under investigation. Is there any known restrictions in GPIO1 module wake-up capability when mpu is in sleep and core active? Any other known restrictions? > > I don't think STATUS is necessary. It’s a write 1 to clear register and should re-latch once there is data. > > As a side note I was noting that the SMC9211 etherchip actually may need a dvfs pre-post notifier. During DVFS spurious interrupt events cause the interface to disable interrupts on its own on some tests. > > Regards, > Richard W. > -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-08 6:15 ` Högander Jouni @ 2008-07-08 12:11 ` Woodruff, Richard 2008-07-08 13:41 ` Högander Jouni 0 siblings, 1 reply; 38+ messages in thread From: Woodruff, Richard @ 2008-07-08 12:11 UTC (permalink / raw) To: Högander Jouni Cc: Premi, Sanjeev, Kalle Jokiniemi, Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org > > > > For sure save/restore of IRQENABLE is needed. Our Labrador board > > which has Ethernet on per-gpio would stop to function after an OFF > > mode transition with out this save and restore (using CDP reference > > code). > > I think this is not related to OFF mode, because OFF state is not > used on the boot. This problem seems to disappear when boot is > done and C6 state is started to be used. Currently it seems to me that > this problem exists if using states where mpu is in sleep state and > core is active (C2, C3). This is under investigation. Is there any > known restrictions in GPIO1 module wake-up capability when mpu is in > sleep and core active? Any other known restrictions? If core is ACTIVE and irq is enabled at MPU then everything should work on any gpio block. If the core is INACTIVE (which is possible with hardware auto's on) then the same holds from above IF you have also enabled all wakeup mechanisms. If the core is in RET/OFF only selected gpio's will wake the system up. IIRC not all GPIO1 even are capable to wake you from this level of sleep. I don't recall the list. You do have the ability to use an IO PAD wake up to wake from those while in RET/OFF. However, I don't believe you will get an IO pad when you in INACTIVE/ACTIVE. You do have to program for this event to be generated at the pad and in the wakeup domain control registers. Questions might be: - Has the prcm init happened and is the entire wake up path been setup? [x] Has anyone fixed the broken gpio wakeup enable code? Right now this might even kill you as it will clear you wakeup enable register. This could stop you from waking from a partially idle/clock stop condition on the L3? Regards, Richard W. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-08 12:11 ` Woodruff, Richard @ 2008-07-08 13:41 ` Högander Jouni 2008-07-08 13:52 ` Woodruff, Richard 0 siblings, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-07-08 13:41 UTC (permalink / raw) To: ext Woodruff, Richard Cc: Premi, Sanjeev, Kalle Jokiniemi, Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org "ext Woodruff, Richard" <r-woodruff2@ti.com> writes: >> > >> > For sure save/restore of IRQENABLE is needed. Our Labrador board >> > which has Ethernet on per-gpio would stop to function after an OFF >> > mode transition with out this save and restore (using CDP reference >> > code). >> >> I think this is not related to OFF mode, because OFF state is not >> used on the boot. This problem seems to disappear when boot is >> done and C6 state is started to be used. Currently it seems to me that >> this problem exists if using states where mpu is in sleep state and >> core is active (C2, C3). This is under investigation. Is there any >> known restrictions in GPIO1 module wake-up capability when mpu is in >> sleep and core active? Any other known restrictions? > > If core is ACTIVE and irq is enabled at MPU then everything should work on any gpio block. > > If the core is INACTIVE (which is possible with hardware auto's on) then the same holds from above IF you have also enabled all wakeup mechanisms. > > If the core is in RET/OFF only selected gpio's will wake the system up. IIRC not all GPIO1 even are capable to wake you from this level of sleep. I don't recall the list. > > You do have the ability to use an IO PAD wake up to wake from those while in RET/OFF. However, I don't believe you will get an IO pad when you in INACTIVE/ACTIVE. You do have to program for this event to be generated at the pad and in the wakeup domain control registers. > > Questions might be: > - Has the prcm init happened and is the entire wake up path been setup? > > [x] Has anyone fixed the broken gpio wakeup enable code? > Right now this might even kill you as it will clear you > wakeup enable register. This could stop you from waking > from a partially idle/clock stop condition on the L3? The problem was actually related to this. There is those gpio_prepare_* and gpio_resume_* functions which were not run. For some reason next_state for powerdomains doesn't update correctly before hw_sup mode is disabled. This caused problem that cpuidle thinks that core is entering ON state, while it was actually entering state written in omap3_pm_init. Now as cpuidle was thinking that core is not entering any sleep state it didn't run gpio_prepare_* and gpio_resume_* functions. This caused that interrupt was not generated for that gpio used by eth chip. This was fixed in my patches by disabling hw_sup mode before writing next_state and then re-enable it. Those patches are also writing next state if CORE next state is ON. > > Regards, > Richard W. > -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-08 13:41 ` Högander Jouni @ 2008-07-08 13:52 ` Woodruff, Richard 2008-07-09 6:48 ` Högander Jouni 0 siblings, 1 reply; 38+ messages in thread From: Woodruff, Richard @ 2008-07-08 13:52 UTC (permalink / raw) To: Högander Jouni Cc: Premi, Sanjeev, Kalle Jokiniemi, Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org > > [x] Has anyone fixed the broken gpio wakeup enable code? > > Right now this might even kill you as it will clear you > > wakeup enable register. This could stop you from waking > > from a partially idle/clock stop condition on the L3? > > The problem was actually related to this. There is those > gpio_prepare_* > and gpio_resume_* functions which were not run. For some reason > next_state for powerdomains doesn't update correctly before hw_sup > mode is disabled. This caused problem that cpuidle thinks that core is > entering ON state, while it was actually entering state written in > omap3_pm_init. Now as cpuidle was thinking that core is not entering > any sleep state it didn't run gpio_prepare_* and gpio_resume_* > functions. This caused that interrupt was not generated for that gpio > used by eth chip. > > This was fixed in my patches by disabling hw_sup mode before writing > next_state and then re-enable it. Those patches are also writing next > state if CORE next state is ON. Ok. As I sent in my mail a couple weeks back. The clearing of wakeup events at GPIOs when the CORE hits INACTIVE might result in windows of you not waking up, especially with dynamic tick in the system. I would guess the windows would be around boot & suspend resume. It is not so clear if gpio that hack is even needed on OMAP3. There is some warning about spurious interrupts when going to RET/OFF for OMAP2. I don't recall for OMAP3. didn't those prepare functions dink with wake up masks in fear of spurious interrupts. So, wasn't the result for you the opposite, it kept you from waking, instead of suppressing extra wakes? Did you fix the OMAP2 GPIO wakeup mask in use at least? The code had a hardcoded mask based on OMAP2 wakeup capable gpios which don't apply to omap3. Regards, Richard W. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-08 13:52 ` Woodruff, Richard @ 2008-07-09 6:48 ` Högander Jouni 2008-07-09 16:31 ` Woodruff, Richard 0 siblings, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-07-09 6:48 UTC (permalink / raw) To: ext Woodruff, Richard Cc: Premi, Sanjeev, Kalle Jokiniemi, Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org "ext Woodruff, Richard" <r-woodruff2@ti.com> writes: >> > [x] Has anyone fixed the broken gpio wakeup enable code? >> > Right now this might even kill you as it will clear you >> > wakeup enable register. This could stop you from waking >> > from a partially idle/clock stop condition on the L3? >> >> The problem was actually related to this. There is those >> gpio_prepare_* >> and gpio_resume_* functions which were not run. For some reason >> next_state for powerdomains doesn't update correctly before hw_sup >> mode is disabled. This caused problem that cpuidle thinks that core is >> entering ON state, while it was actually entering state written in >> omap3_pm_init. Now as cpuidle was thinking that core is not entering >> any sleep state it didn't run gpio_prepare_* and gpio_resume_* >> functions. This caused that interrupt was not generated for that gpio >> used by eth chip. >> >> This was fixed in my patches by disabling hw_sup mode before writing >> next_state and then re-enable it. Those patches are also writing next >> state if CORE next state is ON. > > Ok. As I sent in my mail a couple weeks back. The clearing of wakeup events at GPIOs when the CORE hits INACTIVE might result in windows of you not waking up, especially with dynamic tick in the system. I would guess the windows would be around boot & suspend resume. > > It is not so clear if gpio that hack is even needed on OMAP3. There is some warning about spurious interrupts when going to RET/OFF for OMAP2. I don't recall for OMAP3. didn't those prepare functions dink with wake up masks in fear of spurious interrupts. So, wasn't the result for you the opposite, it kept you from waking, instead of suppressing extra wakes? > > Did you fix the OMAP2 GPIO wakeup mask in use at least? The code > had a hardcoded mask based on OMAP2 wakeup capable gpios which don't > apply to omap3. No I haven't modified that code. I have begun to use it before retention because it is under #if defined(CONFIG_ARCH_OMAP34XX) statement and used in case of omap2. Maybe we could stop using it in case of omap3 at least this comment in gpio.c supports this: "See OMAP2420 Errata item 1.101"? Seems to be just legacy code from omap2. -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-09 6:48 ` Högander Jouni @ 2008-07-09 16:31 ` Woodruff, Richard 0 siblings, 0 replies; 38+ messages in thread From: Woodruff, Richard @ 2008-07-09 16:31 UTC (permalink / raw) To: Högander Jouni Cc: Premi, Sanjeev, Kalle Jokiniemi, Nayak, Rajendra, 'Peter 'p2' De Schrijver', linux-omap@vger.kernel.org > > It is not so clear if gpio that hack is even needed on OMAP3. There > is some warning about spurious interrupts when going to RET/OFF for > OMAP2. I don't recall for OMAP3. didn't those prepare functions dink > with wake up masks in fear of spurious interrupts. So, wasn't the > result for you the opposite, it kept you from waking, instead of > suppressing extra wakes? > > > > Did you fix the OMAP2 GPIO wakeup mask in use at least? The code > > had a hardcoded mask based on OMAP2 wakeup capable gpios which don't > > apply to omap3. > > No I haven't modified that code. I have begun to use it before > retention because it is under #if defined(CONFIG_ARCH_OMAP34XX) > statement and used in case of omap2. Maybe we could stop using it in > case of omap3 at least this comment in gpio.c supports this: "See > OMAP2420 Errata item 1.101"? Seems to be just legacy code from omap2. Yes, that section needs to be reworked. It was probably the root cause of your failure. Regards, Richard W. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 9:32 ` Högander Jouni 2008-07-04 9:45 ` Koen Kooi 2008-07-04 9:45 ` Rajendra Nayak @ 2008-07-04 11:05 ` Peter 'p2' De Schrijver 2008-07-04 11:39 ` Peter 'p2' De Schrijver 2 siblings, 1 reply; 38+ messages in thread From: Peter 'p2' De Schrijver @ 2008-07-04 11:05 UTC (permalink / raw) To: Högander Jouni; +Cc: ext Rajendra Nayak, linux-omap > > So Rajendra sent his uImage and it works quite ok what comes to off > mode on my sdp board. I still see problems with serial console (slow) > and on boot I need to generate manually interrupts to get it to > boot. Otherwise board hangs at this point: > > eth0: link up > Sending DHCP requests ., OK > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.101 > IP-Config: Complete: > device=eth0, addr=192.168.2.101, mask=255.255.255.0, > gw=192.168.2.1, > host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none), > bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath= > Looking up port of RPC 100003/2 on 172.22.146.197 > Looking up port of RPC 100005/1 on 172.22.146.197 > VFS: Mounted root (nfs filesystem). > Freeing init memory: 108K > > Rajendra, are you still using .config file you sent to me? Are all the > changes in your tree available in l-o list. I tried the same uImage here on my SDP. It goes to off nicely after bootup, but after using the console, VDD2 does not to off anymore. VDD1 does go to off. Cheers, Peter. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-04 11:05 ` Peter 'p2' De Schrijver @ 2008-07-04 11:39 ` Peter 'p2' De Schrijver 0 siblings, 0 replies; 38+ messages in thread From: Peter 'p2' De Schrijver @ 2008-07-04 11:39 UTC (permalink / raw) To: Högander Jouni; +Cc: ext Rajendra Nayak, linux-omap > > I tried the same uImage here on my SDP. It goes to off nicely after > bootup, but after using the console, VDD2 does not to off anymore. VDD1 > does go to off. I reverted the u-boot patch to allow IOPAD wakeup on UART and now it works. Cheers, Peter. -- goa is a state of mind ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-01 14:16 [PATCH 00/11] OMAP3 CPUidle patches Rajendra Nayak 2008-07-02 13:11 ` Peter 'p2' De Schrijver @ 2008-07-03 5:57 ` Högander Jouni 2008-07-03 10:20 ` Rajendra Nayak 2008-07-15 13:20 ` Rajendra Nayak ` (2 subsequent siblings) 4 siblings, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-07-03 5:57 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap "ext Rajendra Nayak" <rnayak@ti.com> writes: > Hi, > > The following patches define and enable all of the below mentioned C states for OMAP3. > These are tested with a minimal kernel config on OMAP3430sdp as most drivers today don't have context save/restore in place and > some even lack aggresive clock handling. > These apply on top of the workaround patch set submitted by Jouni. > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > The following is neccessay even with a minimal config to achieve OFF. > $ echo 1 > /sys/power/sleep_while_idle > $ echo 1 > /sys/power/clocks_off_while_idle > > The following C states are defined > C0 - System executing code > C1 - MPU WFI + Core active > C2 - MPU CSWR + Core active > C3 - MPU OFF + Core active > C4 - MPU CSWR + Core CSWR > C5 - MPU OFF + Core CSWR > C6 - MPU OFF + Core OFF > > regards, > Rajendra One more general comment on these patches as I looked at the code after applying them. Most of the code in omap3_enter_idle in cpuidle34xx.c could be shared between suspend/pm_idle/cpuidle. I would do these changes to share this code between these three things: 1. read mpu_pd pwrst, neon_pd pwrst, core_pd pwrst values in omap_sram_idle in pm34xx.c 2. Move all the logic from omap3_enter_idle to omap_sram_idle. Use values read in previous step to decide wether ctx savings/restores are needed, what should be written to neon_pd next_pwrst, wether omap2_gpio_prepare_for/resume_after_retention is needed, wether to disable/enable serial and gpio clocks. Basically what is left into omap3_enter_idle is writing next pwrsts and cpuidle related stuff, something like this: static int omap3_enter_idle(struct cpuidle_device *dev, struct cpuidle_state *state) { struct omap3_processor_cx *cx = cpuidle_get_statedata(state); struct timespec ts_preidle, ts_postidle, ts_idle; struct powerdomain *mpu_pd, *core_pd; current_cx_state = *cx; if (cx->type == OMAP3_STATE_C0) { /* Do nothing for C0, not even a wfi */ return 0; } local_irq_disable(); local_fiq_disable(); /* Used to keep track of the total time in idle */ getnstimeofday(&ts_preidle); if (cx->type > OMAP3_STATE_C1) sched_clock_idle_sleep_event(); /* about to enter deep idle */ mpu_pd = pwrdm_lookup("mpu_pwrdm"); core_pd = pwrdm_lookup("core_pwrdm"); pwrdm_set_next_pwrst(mpu_pd, cx->mpu_state); pwrdm_set_next_pwrst(core_pd, cx->core_state); if (omap_irq_pending()) goto return_sleep_time; /* Execute ARM wfi */ omap_sram_idle(); return_sleep_time: getnstimeofday(&ts_postidle); ts_idle = timespec_sub(ts_postidle, ts_preidle); if (cx->type > OMAP3_STATE_C1) sched_clock_idle_wakeup_event(timespec_to_ns(&ts_idle)); local_irq_enable(); local_fiq_disable(); return (u32)timespec_to_ns(&ts_idle)/1000; } If this is not done, we need to copy paste code from omap3_enter_idle into suspend code anyway if we want to use offmode in it. It would be more nice to have one funcion with this logic shared between suspend/pm_idle/cpuidle rather than two or even three copies of it. -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-03 5:57 ` Högander Jouni @ 2008-07-03 10:20 ` Rajendra Nayak 0 siblings, 0 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-07-03 10:20 UTC (permalink / raw) To: '"Högander" Jouni'; +Cc: linux-omap > -----Original Message----- > From: "Högander" Jouni [mailto:jouni.hogander@nokia.com] > Sent: Thursday, July 03, 2008 11:28 AM > To: ext Rajendra Nayak > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches > > "ext Rajendra Nayak" <rnayak@ti.com> writes: > > > Hi, > > > > The following patches define and enable all of the below > mentioned C states for OMAP3. > > These are tested with a minimal kernel config on > OMAP3430sdp as most drivers today don't have context > save/restore in place and > > some even lack aggresive clock handling. > > These apply on top of the workaround patch set submitted by Jouni. > > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > > > The following is neccessay even with a minimal config to > achieve OFF. > > $ echo 1 > /sys/power/sleep_while_idle > > $ echo 1 > /sys/power/clocks_off_while_idle > > > > The following C states are defined > > C0 - System executing code > > C1 - MPU WFI + Core active > > C2 - MPU CSWR + Core active > > C3 - MPU OFF + Core active > > C4 - MPU CSWR + Core CSWR > > C5 - MPU OFF + Core CSWR > > C6 - MPU OFF + Core OFF > > > > regards, > > Rajendra > > One more general comment on these patches as I looked at the code > after applying them. > > Most of the code in omap3_enter_idle in cpuidle34xx.c could be shared > between suspend/pm_idle/cpuidle. I would do these changes to share > this code between these three things: > > 1. read mpu_pd pwrst, neon_pd pwrst, core_pd pwrst values in > omap_sram_idle in pm34xx.c > > 2. Move all the logic from omap3_enter_idle to omap_sram_idle. Use > values read in previous step to decide wether ctx savings/restores > are needed, what should be written to neon_pd next_pwrst, wether > omap2_gpio_prepare_for/resume_after_retention is needed, wether to > disable/enable serial and gpio clocks. > > Basically what is left into omap3_enter_idle is writing next pwrsts > and cpuidle related stuff, something like this: > > static int omap3_enter_idle(struct cpuidle_device *dev, > struct cpuidle_state *state) > { > struct omap3_processor_cx *cx = cpuidle_get_statedata(state); > struct timespec ts_preidle, ts_postidle, ts_idle; > struct powerdomain *mpu_pd, *core_pd; > > current_cx_state = *cx; > > if (cx->type == OMAP3_STATE_C0) { > /* Do nothing for C0, not even a wfi */ > return 0; > } > > local_irq_disable(); > local_fiq_disable(); > > /* Used to keep track of the total time in idle */ > getnstimeofday(&ts_preidle); > > if (cx->type > OMAP3_STATE_C1) > sched_clock_idle_sleep_event(); /* about to > enter deep idle */ > > mpu_pd = pwrdm_lookup("mpu_pwrdm"); > core_pd = pwrdm_lookup("core_pwrdm"); > > pwrdm_set_next_pwrst(mpu_pd, cx->mpu_state); > pwrdm_set_next_pwrst(core_pd, cx->core_state); > > if (omap_irq_pending()) > goto return_sleep_time; > > /* Execute ARM wfi */ > omap_sram_idle(); > > return_sleep_time: > getnstimeofday(&ts_postidle); > ts_idle = timespec_sub(ts_postidle, ts_preidle); > > if (cx->type > OMAP3_STATE_C1) > sched_clock_idle_wakeup_event(timespec_to_ns(&ts_idle)); > > local_irq_enable(); > local_fiq_disable(); > > return (u32)timespec_to_ns(&ts_idle)/1000; > } > > If this is not done, we need to copy paste code from omap3_enter_idle > into suspend code anyway if we want to use offmode in it. It would be > more nice to have one funcion with this logic shared between > suspend/pm_idle/cpuidle rather than two or even three copies of it. Yes, all this looks good to me. > > -- > Jouni Högander > > -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches 2008-07-01 14:16 [PATCH 00/11] OMAP3 CPUidle patches Rajendra Nayak 2008-07-02 13:11 ` Peter 'p2' De Schrijver 2008-07-03 5:57 ` Högander Jouni @ 2008-07-15 13:20 ` Rajendra Nayak 2008-07-18 13:18 ` [PATCH 00/11] OMAP3 CPUidle patches - ver 2 Rajendra Nayak [not found] ` <002f01c8f7c5$0790fea0$LocalHost@wipultra1382> 4 siblings, 0 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-07-15 13:20 UTC (permalink / raw) To: linux-omap Did some idle measurements with these.. VDD1 : 2.0 mA VDD2 : 2.3 mA The numbers are on the higher side as the thresholds are still not optimal. Currently C6 has a threshold set to 300 ms which seems to be very low. We are working on deriving the optimal thresholds for each C state. > -----Original Message----- > From: linux-omap-owner@vger.kernel.org > [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Rajendra Nayak > Sent: Tuesday, July 01, 2008 7:46 PM > To: linux-omap@vger.kernel.org > Subject: [PATCH 00/11] OMAP3 CPUidle patches > > Hi, > > The following patches define and enable all of the below > mentioned C states for OMAP3. > These are tested with a minimal kernel config on OMAP3430sdp > as most drivers today don't have context save/restore in place and > some even lack aggresive clock handling. > These apply on top of the workaround patch set submitted by Jouni. > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > The following is neccessay even with a minimal config to achieve OFF. > $ echo 1 > /sys/power/sleep_while_idle > $ echo 1 > /sys/power/clocks_off_while_idle > > The following C states are defined > C0 - System executing code > C1 - MPU WFI + Core active > C2 - MPU CSWR + Core active > C3 - MPU OFF + Core active > C4 - MPU CSWR + Core CSWR > C5 - MPU OFF + Core CSWR > C6 - MPU OFF + Core OFF > > regards, > Rajendra > > > > -- > 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] 38+ messages in thread
* [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-07-01 14:16 [PATCH 00/11] OMAP3 CPUidle patches Rajendra Nayak ` (2 preceding siblings ...) 2008-07-15 13:20 ` Rajendra Nayak @ 2008-07-18 13:18 ` Rajendra Nayak [not found] ` <002f01c8f7c5$0790fea0$LocalHost@wipultra1382> 4 siblings, 0 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-07-18 13:18 UTC (permalink / raw) To: linux-omap Hi, I am sending an updated patch set for CPUidle which includes all fixes/comments posted on the previous set by Jouni/Richard W/Peter and others. The Following are the fixes 1) Uart clock enable/disable moved out of the context save/restore patch 2) GPIO IRQENABLE save/restore fix from Richard 3) Fixes from Jouni which do the following 1. Add wkdep between neon and mpu 2. Add wkdep between per and core 3. Deny hwsup mode before writing next pwrst state 4. Make sure that order in idle loop is such that clocks are _really_ enabled before accessing registers (serial & gpio). 4) Safe state idle fix from Richard 5) Uart smart-force fix from Richard 6) Toggle IO-PAD enable/disable in idle As earlier these patches apply on top of Jouni's workaround patch set ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) The following is neccessay even with a minimal config to achieve OFF. $ echo 1 > /sys/power/sleep_while_idle $ echo 1 > /sys/power/clocks_off_while_idle regards, Rajendra ^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <002f01c8f7c5$0790fea0$LocalHost@wipultra1382>]
* [PATCH 00/11] OMAP3 CPUidle patches - ver 2 [not found] ` <002f01c8f7c5$0790fea0$LocalHost@wipultra1382> @ 2008-08-06 13:12 ` Rajendra Nayak 2008-08-07 9:54 ` Kalle Jokiniemi ` (2 more replies) 0 siblings, 3 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-08-06 13:12 UTC (permalink / raw) To: linux-omap Hi, Re-posting a refreshed version of these patches. regards Rajendra > Hi, > > I am sending an updated patch set for CPUidle which includes all > fixes/comments > posted on the previous set by Jouni/Richard W/Peter and others. > > The Following are the fixes > 1) Uart clock enable/disable moved out of the context save/restore patch > 2) GPIO IRQENABLE save/restore fix from Richard > 3) Fixes from Jouni which do the following > 1. Add wkdep between neon and mpu > 2. Add wkdep between per and core > 3. Deny hwsup mode before writing next pwrst state > 4. Make sure that order in idle loop is such that clocks are > _really_ > enabled before accessing registers (serial & gpio). > 4) Safe state idle fix from Richard > 5) Uart smart-force fix from Richard > 6) Toggle IO-PAD enable/disable in idle > > As earlier these patches apply on top of Jouni's workaround patch set > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > The following is neccessay even with a minimal config to achieve OFF. > $ echo 1 > /sys/power/sleep_while_idle > $ echo 1 > /sys/power/clocks_off_while_idle > > regards, > Rajendra > ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-06 13:12 ` Rajendra Nayak @ 2008-08-07 9:54 ` Kalle Jokiniemi 2008-08-12 12:40 ` Högander Jouni 2008-08-19 19:08 ` Paul Walmsley 2 siblings, 0 replies; 38+ messages in thread From: Kalle Jokiniemi @ 2008-08-07 9:54 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap On ke, 2008-08-06 at 18:42 +0530, ext Rajendra Nayak wrote: > Hi, > > Re-posting a refreshed version of these patches. I'm getting this error when trying to apply these patches with 'git-am' command: $ git-am ~/.evolution/mail/local/stage Applying Basic cpuidle driver fatal: patch fragment without header at line 13: @@ -0,0 +1,245 @@ Patch failed at 0001. with manual "patch -p 1 < .dotest/0001" they apply nicely, but it is very time-consuming to do it manually for each patch. Do you use normal git-format-patch and git-send-email to format and post the patches? Br, Kalle > > regards > Rajendra > > > Hi, > > > > I am sending an updated patch set for CPUidle which includes all > > fixes/comments > > posted on the previous set by Jouni/Richard W/Peter and others. > > > > The Following are the fixes > > 1) Uart clock enable/disable moved out of the context save/restore patch > > 2) GPIO IRQENABLE save/restore fix from Richard > > 3) Fixes from Jouni which do the following > > 1. Add wkdep between neon and mpu > > 2. Add wkdep between per and core > > 3. Deny hwsup mode before writing next pwrst state > > 4. Make sure that order in idle loop is such that clocks are > > _really_ > > enabled before accessing registers (serial & gpio). > > 4) Safe state idle fix from Richard > > 5) Uart smart-force fix from Richard > > 6) Toggle IO-PAD enable/disable in idle > > > > As earlier these patches apply on top of Jouni's workaround patch set > > ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > > > > The following is neccessay even with a minimal config to achieve OFF. > > $ echo 1 > /sys/power/sleep_while_idle > > $ echo 1 > /sys/power/clocks_off_while_idle > > > > regards, > > Rajendra > > > > > -- > 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] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-06 13:12 ` Rajendra Nayak 2008-08-07 9:54 ` Kalle Jokiniemi @ 2008-08-12 12:40 ` Högander Jouni 2008-08-13 5:57 ` Rajendra Nayak 2008-08-19 19:08 ` Paul Walmsley 2 siblings, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-08-12 12:40 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap Hi Rajendra, "ext Rajendra Nayak" <rnayak@ti.com> writes: > Hi, > > Re-posting a refreshed version of these patches. > > regards > Rajendra I think these are beginning to look good to me, altought patches can't be applied using git. Few things: Check wether serial can sleep is missing from omap3_enter_idle and it should be removed from omap3_can_sleep: diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index a02da6d..16ff30b 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -431,7 +431,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev, current_cx_state = *cx; - if (cx->type == OMAP3_STATE_C0) { + if (cx->type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) { /* Do nothing for C0, not even a wfi */ return 0; } diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644 @@ -391,8 +391,6 @@ int omap3_can_sleep(void) return 0; if (atomic_read(&sleep_block) > 0) return 0; - if (!omap_serial_can_sleep()) - return 0; return 1; } Doing this would make serial console to work faster. _omap_sram_idle should be non-static: diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -60,7 +60,7 @@ u32 restore_pointer_address; static LIST_HEAD(pwrst_list); -static void (*_omap_sram_idle)(u32 *addr, int save_state); +void (*_omap_sram_idle)(u32 *addr, int save_state); static void (*saved_idle)(void); Serial and gpio clock disabling and gpio_prepare/resume can be removed from omap3_pm_idle because they are already done in omap_sram_idle. And if omap_serial_can_sleep is removed from omap3_can_sleep it should be added to omap3_pm_idle. Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE: +#ifndef CONFIG_CPU_IDLE static void omap3_pm_idle(void) { local_irq_disable(); @@ -454,33 +455,16 @@ static void omap3_pm_idle(void) if (omap_irq_pending()) goto out; - omap2_gpio_prepare_for_retention(); - - if (clocks_off_while_idle) { - omap_serial_enable_clocks(0, 0); - omap_serial_enable_clocks(0, 1); - omap_serial_enable_clocks(0, 2); - /* XXX This is for gpio fclk hack. Will be removed as - * gpio driver * handles fcks correctly */ - per_gpio_clk_disable(); - } + if (!omap_serial_can_sleep()) + goto out; omap_sram_idle(); - if (clocks_off_while_idle) { - omap_serial_enable_clocks(1, 0); - omap_serial_enable_clocks(1, 1); - omap_serial_enable_clocks(1, 2); - /* XXX This is for gpio fclk hack. Will be removed as - * gpio driver * handles fcks correctly */ - per_gpio_clk_enable(); - } - - omap2_gpio_resume_after_retention(); out: local_fiq_enable(); local_irq_enable(); } +#endif /* CONFIG_CPU_IDLE */ I would like to see also some reformatting. E.g. patch 11 contains lots of code which is not related to "CORE context save/restore". It might be also good idea to enable only non-off mode C states and have a pwrdms_setup function which is something like this: static int __init pwrdms_setup(struct powerdomain *pwrdm) { struct power_state *pwrst; if (!pwrdm->pwrsts) return 0; pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL); if (!pwrst) return -ENOMEM; pwrst->pwrdm = pwrdm; pwrst->next_state = PWRDM_POWER_RET; list_add(&pwrst->node, &pwrst_list); if (pwrdm_has_hdwr_sar(pwrdm)) pwrdm_enable_hdwr_sar(pwrdm); #ifdef CONFIG_CPU_IDLE /* Let cpuidle do selection here */ if (!strcmp(pwrst->pwrdm->name, "core_pwrdm") || !strcmp(pwrst->pwrdm->name, "mpu_pwrdm") || !strcmp(pwrst->pwrdm->name, "neon_pwrdm")) return set_pwrdm_state(pwrst->pwrdm, PWRDM_POWER_ON); else #endif return set_pwrdm_state(pwrst->pwrdm, pwrst->next_state); } This way cpuidle code would be in a state that it could be applied on linux-omap tree and it wouldn't break anything. Then have e.g. separate patch for testing off state. This patch could modify code to set next states to off and mark off mode C states as a valid. > >> Hi, >> >> I am sending an updated patch set for CPUidle which includes all >> fixes/comments >> posted on the previous set by Jouni/Richard W/Peter and others. >> >> The Following are the fixes >> 1) Uart clock enable/disable moved out of the context save/restore patch >> 2) GPIO IRQENABLE save/restore fix from Richard >> 3) Fixes from Jouni which do the following >> 1. Add wkdep between neon and mpu >> 2. Add wkdep between per and core >> 3. Deny hwsup mode before writing next pwrst state >> 4. Make sure that order in idle loop is such that clocks are >> _really_ >> enabled before accessing registers (serial & gpio). >> 4) Safe state idle fix from Richard >> 5) Uart smart-force fix from Richard >> 6) Toggle IO-PAD enable/disable in idle >> >> As earlier these patches apply on top of Jouni's workaround patch set >> ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) >> >> The following is neccessay even with a minimal config to achieve OFF. >> $ echo 1 > /sys/power/sleep_while_idle >> $ echo 1 > /sys/power/clocks_off_while_idle >> >> regards, >> Rajendra >> > > > -- > 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 > > -- Jouni Högander -- 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 related [flat|nested] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-12 12:40 ` Högander Jouni @ 2008-08-13 5:57 ` Rajendra Nayak 2008-08-13 6:06 ` Rajendra Nayak 2008-08-13 6:55 ` Högander Jouni 0 siblings, 2 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-08-13 5:57 UTC (permalink / raw) To: '"Högander" Jouni'; +Cc: linux-omap > > Check wether serial can sleep is missing from > omap3_enter_idle and it should be removed from omap3_can_sleep: > > diff --git a/arch/arm/mach-omap2/cpuidle34xx.c > b/arch/arm/mach-omap2/cpuidle34xx.c > index a02da6d..16ff30b 100644 > --- a/arch/arm/mach-omap2/cpuidle34xx.c > +++ b/arch/arm/mach-omap2/cpuidle34xx.c > @@ -431,7 +431,7 @@ static int omap3_enter_idle(struct > cpuidle_device *dev, > > current_cx_state = *cx; > > - if (cx->type == OMAP3_STATE_C0) { > + if (cx->type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) { > /* Do nothing for C0, not even a wfi */ > return 0; > } > > diff --git a/arch/arm/mach-omap2/pm34xx.c > b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644 > @@ -391,8 +391,6 @@ int omap3_can_sleep(void) > return 0; > if (atomic_read(&sleep_block) > 0) > return 0; > - if (!omap_serial_can_sleep()) > - return 0; > return 1; > } > > Doing this would make serial console to work faster. Yes, I removed these in my patches and put in the changes suggested by Richard in 8250.c I thought the final conclusion of the discussion was that it was too expensive to the keep the system in C0 all the time while UART inactivity runs, or did I miss something? > > _omap_sram_idle should be non-static: > > diff --git a/arch/arm/mach-omap2/pm34xx.c > b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644 > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -60,7 +60,7 @@ u32 restore_pointer_address; > > static LIST_HEAD(pwrst_list); > > -static void (*_omap_sram_idle)(u32 *addr, int save_state); > +void (*_omap_sram_idle)(u32 *addr, int save_state); > > static void (*saved_idle)(void); I thought this is already part of the patches. It is now non-static. > > Serial and gpio clock disabling and gpio_prepare/resume can > be removed from omap3_pm_idle because they are already done > in omap_sram_idle. And if omap_serial_can_sleep is removed > from omap3_can_sleep it should be added to omap3_pm_idle. > Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE: > > +#ifndef CONFIG_CPU_IDLE > static void omap3_pm_idle(void) > { > local_irq_disable(); > @@ -454,33 +455,16 @@ static void omap3_pm_idle(void) > if (omap_irq_pending()) > goto out; > > - omap2_gpio_prepare_for_retention(); > - > - if (clocks_off_while_idle) { > - omap_serial_enable_clocks(0, 0); > - omap_serial_enable_clocks(0, 1); > - omap_serial_enable_clocks(0, 2); > - /* XXX This is for gpio fclk hack. Will be removed as > - * gpio driver * handles fcks correctly */ > - per_gpio_clk_disable(); > - } > + if (!omap_serial_can_sleep()) > + goto out; > > omap_sram_idle(); > > - if (clocks_off_while_idle) { > - omap_serial_enable_clocks(1, 0); > - omap_serial_enable_clocks(1, 1); > - omap_serial_enable_clocks(1, 2); > - /* XXX This is for gpio fclk hack. Will be removed as > - * gpio driver * handles fcks correctly */ > - per_gpio_clk_enable(); > - } > - > - omap2_gpio_resume_after_retention(); > out: > local_fiq_enable(); > local_irq_enable(); > } > +#endif /* CONFIG_CPU_IDLE */ These are also done as part of the last patch in the series. > > I would like to see also some reformatting. E.g. patch 11 > contains lots of code which is not related to "CORE context > save/restore". It might be also good idea to enable only > non-off mode C states and have a pwrdms_setup function which > is something like this: > > static int __init pwrdms_setup(struct powerdomain *pwrdm) { > struct power_state *pwrst; > > if (!pwrdm->pwrsts) > return 0; > > pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL); > if (!pwrst) > return -ENOMEM; > pwrst->pwrdm = pwrdm; > pwrst->next_state = PWRDM_POWER_RET; > list_add(&pwrst->node, &pwrst_list); > > if (pwrdm_has_hdwr_sar(pwrdm)) > pwrdm_enable_hdwr_sar(pwrdm); > > #ifdef CONFIG_CPU_IDLE > /* Let cpuidle do selection here */ > if (!strcmp(pwrst->pwrdm->name, "core_pwrdm") || > !strcmp(pwrst->pwrdm->name, "mpu_pwrdm") || > !strcmp(pwrst->pwrdm->name, "neon_pwrdm")) > return set_pwrdm_state(pwrst->pwrdm, PWRDM_POWER_ON); > else > #endif > return set_pwrdm_state(pwrst->pwrdm, > pwrst->next_state); } > > This way cpuidle code would be in a state that it could be > applied on linux-omap tree and it wouldn't break anything. > Then have e.g. separate patch for testing off state. This > patch could modify code to set next states to off and mark > off mode C states as a valid. Yes, will do that. Maybe the couple of comments above are also due to the last patch doing a lot more than it actually should. > > > > >> Hi, > >> > >> I am sending an updated patch set for CPUidle which includes all > >> fixes/comments posted on the previous set by Jouni/Richard W/Peter > >> and others. > >> > >> The Following are the fixes > >> 1) Uart clock enable/disable moved out of the context save/restore > >> patch > >> 2) GPIO IRQENABLE save/restore fix from Richard > >> 3) Fixes from Jouni which do the following > >> 1. Add wkdep between neon and mpu > >> 2. Add wkdep between per and core > >> 3. Deny hwsup mode before writing next pwrst state > >> 4. Make sure that order in idle loop is such that clocks are > >> _really_ > >> enabled before accessing registers > (serial & gpio). > >> 4) Safe state idle fix from Richard > >> 5) Uart smart-force fix from Richard > >> 6) Toggle IO-PAD enable/disable in idle > >> > >> As earlier these patches apply on top of Jouni's > workaround patch set > >> ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) > >> > >> The following is neccessay even with a minimal config to > achieve OFF. > >> $ echo 1 > /sys/power/sleep_while_idle $ echo 1 > > >> /sys/power/clocks_off_while_idle > >> > >> regards, > >> Rajendra > >> > > > > > > -- > > 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 > > > > > > -- > Jouni Högander > > > -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-13 5:57 ` Rajendra Nayak @ 2008-08-13 6:06 ` Rajendra Nayak 2008-08-13 6:55 ` Högander Jouni 1 sibling, 0 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-08-13 6:06 UTC (permalink / raw) To: '"Högander" Jouni'; +Cc: linux-omap > > > > > Serial and gpio clock disabling and gpio_prepare/resume can > be removed > > from omap3_pm_idle because they are already done in omap_sram_idle. > > And if omap_serial_can_sleep is removed from > omap3_can_sleep it should > > be added to omap3_pm_idle. > > Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE: > > > > +#ifndef CONFIG_CPU_IDLE > > static void omap3_pm_idle(void) > > { > > local_irq_disable(); > > @@ -454,33 +455,16 @@ static void omap3_pm_idle(void) > > if (omap_irq_pending()) > > goto out; > > > > - omap2_gpio_prepare_for_retention(); > > - > > - if (clocks_off_while_idle) { > > - omap_serial_enable_clocks(0, 0); > > - omap_serial_enable_clocks(0, 1); > > - omap_serial_enable_clocks(0, 2); > > - /* XXX This is for gpio fclk hack. Will be > removed as > > - * gpio driver * handles fcks correctly */ > > - per_gpio_clk_disable(); > > - } > > + if (!omap_serial_can_sleep()) > > + goto out; > > > > omap_sram_idle(); > > > > - if (clocks_off_while_idle) { > > - omap_serial_enable_clocks(1, 0); > > - omap_serial_enable_clocks(1, 1); > > - omap_serial_enable_clocks(1, 2); > > - /* XXX This is for gpio fclk hack. Will be > removed as > > - * gpio driver * handles fcks correctly */ > > - per_gpio_clk_enable(); > > - } > > - > > - omap2_gpio_resume_after_retention(); > > out: > > local_fiq_enable(); > > local_irq_enable(); > > } > > +#endif /* CONFIG_CPU_IDLE */ > > These are also done as part of the last patch in the series. > Ok.. so I misunderstood your comment initially, I confused omap3_pm_idle with the omap3_enter_idle and thought this was already done. Yes, these can be now removed. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-13 5:57 ` Rajendra Nayak 2008-08-13 6:06 ` Rajendra Nayak @ 2008-08-13 6:55 ` Högander Jouni 2008-08-13 12:35 ` Woodruff, Richard 1 sibling, 1 reply; 38+ messages in thread From: Högander Jouni @ 2008-08-13 6:55 UTC (permalink / raw) To: ext Rajendra Nayak; +Cc: linux-omap "ext Rajendra Nayak" <rnayak@ti.com> writes: >> >> Check wether serial can sleep is missing from >> omap3_enter_idle and it should be removed from omap3_can_sleep: >> >> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c >> b/arch/arm/mach-omap2/cpuidle34xx.c >> index a02da6d..16ff30b 100644 >> --- a/arch/arm/mach-omap2/cpuidle34xx.c >> +++ b/arch/arm/mach-omap2/cpuidle34xx.c >> @@ -431,7 +431,7 @@ static int omap3_enter_idle(struct >> cpuidle_device *dev, >> >> current_cx_state = *cx; >> >> - if (cx->type == OMAP3_STATE_C0) { >> + if (cx->type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) { >> /* Do nothing for C0, not even a wfi */ >> return 0; >> } >> >> diff --git a/arch/arm/mach-omap2/pm34xx.c >> b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644 >> @@ -391,8 +391,6 @@ int omap3_can_sleep(void) >> return 0; >> if (atomic_read(&sleep_block) > 0) >> return 0; >> - if (!omap_serial_can_sleep()) >> - return 0; >> return 1; >> } >> >> Doing this would make serial console to work faster. > > Yes, I removed these in my patches and put in the changes suggested by Richard > in 8250.c I doubt that your changes to 8250.c will be applied. I have understood that omap specific changes are not accepted to generic 8250 driver. Anyway these changes doesn't help too much. Serial console is annoyingly slow if sleep while idle is enabled. > > I thought the final conclusion of the discussion was that it was too expensive to the keep the > system in C0 all the time while UART inactivity runs, or did I miss > something? This was misunderstanding. C0 is selected only for 5 seconds after last activity on serial console rx line. After this 5 second sleep prevention, cpuidle continues state selection normally. I don't see this too expensive, what do you think? > >> >> _omap_sram_idle should be non-static: >> >> diff --git a/arch/arm/mach-omap2/pm34xx.c >> b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644 >> --- a/arch/arm/mach-omap2/pm34xx.c >> +++ b/arch/arm/mach-omap2/pm34xx.c >> @@ -60,7 +60,7 @@ u32 restore_pointer_address; >> >> static LIST_HEAD(pwrst_list); >> >> -static void (*_omap_sram_idle)(u32 *addr, int save_state); >> +void (*_omap_sram_idle)(u32 *addr, int save_state); >> >> static void (*saved_idle)(void); > > I thought this is already part of the patches. It is now non-static. Ok, I might have done something wrong with your patches. > >> >> Serial and gpio clock disabling and gpio_prepare/resume can >> be removed from omap3_pm_idle because they are already done >> in omap_sram_idle. And if omap_serial_can_sleep is removed >> from omap3_can_sleep it should be added to omap3_pm_idle. >> Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE: >> >> +#ifndef CONFIG_CPU_IDLE >> static void omap3_pm_idle(void) >> { >> local_irq_disable(); >> @@ -454,33 +455,16 @@ static void omap3_pm_idle(void) >> if (omap_irq_pending()) >> goto out; >> >> - omap2_gpio_prepare_for_retention(); >> - >> - if (clocks_off_while_idle) { >> - omap_serial_enable_clocks(0, 0); >> - omap_serial_enable_clocks(0, 1); >> - omap_serial_enable_clocks(0, 2); >> - /* XXX This is for gpio fclk hack. Will be removed as >> - * gpio driver * handles fcks correctly */ >> - per_gpio_clk_disable(); >> - } >> + if (!omap_serial_can_sleep()) >> + goto out; >> >> omap_sram_idle(); >> >> - if (clocks_off_while_idle) { >> - omap_serial_enable_clocks(1, 0); >> - omap_serial_enable_clocks(1, 1); >> - omap_serial_enable_clocks(1, 2); >> - /* XXX This is for gpio fclk hack. Will be removed as >> - * gpio driver * handles fcks correctly */ >> - per_gpio_clk_enable(); >> - } >> - >> - omap2_gpio_resume_after_retention(); >> out: >> local_fiq_enable(); >> local_irq_enable(); >> } >> +#endif /* CONFIG_CPU_IDLE */ > > These are also done as part of the last patch in the series. I already noticed your second reply. > >> >> I would like to see also some reformatting. E.g. patch 11 >> contains lots of code which is not related to "CORE context >> save/restore". It might be also good idea to enable only >> non-off mode C states and have a pwrdms_setup function which >> is something like this: >> >> static int __init pwrdms_setup(struct powerdomain *pwrdm) { >> struct power_state *pwrst; >> >> if (!pwrdm->pwrsts) >> return 0; >> >> pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL); >> if (!pwrst) >> return -ENOMEM; >> pwrst->pwrdm = pwrdm; >> pwrst->next_state = PWRDM_POWER_RET; >> list_add(&pwrst->node, &pwrst_list); >> >> if (pwrdm_has_hdwr_sar(pwrdm)) >> pwrdm_enable_hdwr_sar(pwrdm); >> >> #ifdef CONFIG_CPU_IDLE >> /* Let cpuidle do selection here */ >> if (!strcmp(pwrst->pwrdm->name, "core_pwrdm") || >> !strcmp(pwrst->pwrdm->name, "mpu_pwrdm") || >> !strcmp(pwrst->pwrdm->name, "neon_pwrdm")) >> return set_pwrdm_state(pwrst->pwrdm, PWRDM_POWER_ON); >> else >> #endif >> return set_pwrdm_state(pwrst->pwrdm, >> pwrst->next_state); } >> >> This way cpuidle code would be in a state that it could be >> applied on linux-omap tree and it wouldn't break anything. >> Then have e.g. separate patch for testing off state. This >> patch could modify code to set next states to off and mark >> off mode C states as a valid. > > Yes, will do that. Maybe the couple of comments above are also due to > the last patch doing a lot more than it actually should. Ok, great. > >> >> > >> >> Hi, >> >> >> >> I am sending an updated patch set for CPUidle which includes all >> >> fixes/comments posted on the previous set by Jouni/Richard W/Peter >> >> and others. >> >> >> >> The Following are the fixes >> >> 1) Uart clock enable/disable moved out of the context save/restore >> >> patch >> >> 2) GPIO IRQENABLE save/restore fix from Richard >> >> 3) Fixes from Jouni which do the following >> >> 1. Add wkdep between neon and mpu >> >> 2. Add wkdep between per and core >> >> 3. Deny hwsup mode before writing next pwrst state >> >> 4. Make sure that order in idle loop is such that clocks are >> >> _really_ >> >> enabled before accessing registers >> (serial & gpio). >> >> 4) Safe state idle fix from Richard >> >> 5) Uart smart-force fix from Richard >> >> 6) Toggle IO-PAD enable/disable in idle >> >> >> >> As earlier these patches apply on top of Jouni's >> workaround patch set >> >> ([PATCH 0/6] 34XX: PM: Workarounds to get omap3 to retention 4th.) >> >> >> >> The following is neccessay even with a minimal config to >> achieve OFF. >> >> $ echo 1 > /sys/power/sleep_while_idle $ echo 1 > >> >> /sys/power/clocks_off_while_idle >> >> >> >> regards, >> >> Rajendra >> >> >> > >> > >> > -- >> > 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 >> > >> > >> >> -- >> Jouni Högander >> >> >> > > > -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-13 6:55 ` Högander Jouni @ 2008-08-13 12:35 ` Woodruff, Richard 2008-08-13 13:12 ` Högander Jouni 2008-08-14 5:25 ` Rajendra Nayak 0 siblings, 2 replies; 38+ messages in thread From: Woodruff, Richard @ 2008-08-13 12:35 UTC (permalink / raw) To: Högander Jouni, Nayak, Rajendra; +Cc: linux-omap@vger.kernel.org > >> Doing this would make serial console to work faster. > > > > Yes, I removed these in my patches and put in the changes suggested by > Richard > > in 8250.c > > I doubt that your changes to 8250.c will be applied. I have understood > that omap specific changes are not accepted to generic 8250 > driver. Anyway these changes doesn't help too much. Serial console is > annoyingly slow if sleep while idle is enabled. Rajendra is it slow in your current builds on this tree with fixes in place? Sluggish serial has NOT been an issue for us in other trees for a long time. Perhaps something is missing. In general keeping code out of the C0 path is good. What ever method makes console serial usable and gets out of the way fastest to get better power measurements in typical test environment is good. Is the comment on the smart idle / no idle aspect or the whole path? It probably is easier to put changes in our local cpu_idle-C0 function as compared to a shared 8250 driver. But if it means adding extra code on a hot system path it is less appealing. If it's working here, we can ask what opinions are on ARM-Linux list. Today there are other UART instance specific work arounds in that code. Regards, Richard W. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-13 12:35 ` Woodruff, Richard @ 2008-08-13 13:12 ` Högander Jouni 2008-08-14 5:25 ` Rajendra Nayak 1 sibling, 0 replies; 38+ messages in thread From: Högander Jouni @ 2008-08-13 13:12 UTC (permalink / raw) To: ext Woodruff, Richard; +Cc: Nayak, Rajendra, linux-omap@vger.kernel.org Hi Richard, "ext Woodruff, Richard" <r-woodruff2@ti.com> writes: >> >> Doing this would make serial console to work faster. >> > >> > Yes, I removed these in my patches and put in the changes suggested by >> Richard >> > in 8250.c >> >> I doubt that your changes to 8250.c will be applied. I have understood >> that omap specific changes are not accepted to generic 8250 >> driver. Anyway these changes doesn't help too much. Serial console is >> annoyingly slow if sleep while idle is enabled. > > Rajendra is it slow in your current builds on this tree with fixes > in place? Sluggish serial has NOT been an issue for us in other > trees for a long time. Perhaps something is missing. Why this is not problem in your trees is probably because you have similiar hack in place. At least in your CDP tree you have 6 second timeout after activity in serial console. While this timeout is on only mpu is allowed to enter sleep state. After this timeout C state selection continues normally. I agree that this is slightly better, but still not providing realistic PM for testing. PER and CORE sleep transitions are still prevented. I think we must remember that serial console is a debug interface. If doing some PM testing, it is not too big task to wait for 5 seconds before starting the test/measurement. > > In general keeping code out of the C0 path is good. What ever method makes console serial usable and gets out of the way fastest to get better power measurements in typical test environment is good. > > Is the comment on the smart idle / no idle aspect or the whole path? My comment was on the changes made to 8250 driver (smart idle / no idle). > > It probably is easier to put changes in our local cpu_idle-C0 function as compared to a shared 8250 driver. But if it means adding extra code on a hot system path it is less appealing. > > If it's working here, we can ask what opinions are on ARM-Linux > list. Today there are other UART instance specific work arounds in > that code. Ok, it would be great to get such code to 8250 driver. > > Regards, > Richard W. > -- Jouni Högander -- 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] 38+ messages in thread
* RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-13 12:35 ` Woodruff, Richard 2008-08-13 13:12 ` Högander Jouni @ 2008-08-14 5:25 ` Rajendra Nayak 1 sibling, 0 replies; 38+ messages in thread From: Rajendra Nayak @ 2008-08-14 5:25 UTC (permalink / raw) To: 'Woodruff, Richard', 'Högander Jouni'; +Cc: linux-omap > -----Original Message----- > From: Woodruff, Richard [mailto:r-woodruff2@ti.com] > Sent: Wednesday, August 13, 2008 6:06 PM > To: Högander Jouni; Nayak, Rajendra > Cc: linux-omap@vger.kernel.org > Subject: RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 > > > >> Doing this would make serial console to work faster. > > > > > > Yes, I removed these in my patches and put in the changes > suggested > > > by > > Richard > > > in 8250.c > > > > I doubt that your changes to 8250.c will be applied. I have > understood > > that omap specific changes are not accepted to generic 8250 driver. > > Anyway these changes doesn't help too much. Serial console is > > annoyingly slow if sleep while idle is enabled. > > Rajendra is it slow in your current builds on this tree with > fixes in place? Sluggish serial has NOT been an issue for us > in other trees for a long time. Perhaps something is missing. Yes, its indeed a bit sluggish in my builds as well. Not as good as what we have in our internal tree. > > In general keeping code out of the C0 path is good. What > ever method makes console serial usable and gets out of the > way fastest to get better power measurements in typical test > environment is good. > > Is the comment on the smart idle / no idle aspect or the whole path? > > It probably is easier to put changes in our local cpu_idle-C0 > function as compared to a shared 8250 driver. But if it > means adding extra code on a hot system path it is less appealing. > > If it's working here, we can ask what opinions are on > ARM-Linux list. Today there are other UART instance specific > work arounds in that code. > > Regards, > Richard W. > > -- 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] 38+ messages in thread
* Re: [PATCH 00/11] OMAP3 CPUidle patches - ver 2 2008-08-06 13:12 ` Rajendra Nayak 2008-08-07 9:54 ` Kalle Jokiniemi 2008-08-12 12:40 ` Högander Jouni @ 2008-08-19 19:08 ` Paul Walmsley 2 siblings, 0 replies; 38+ messages in thread From: Paul Walmsley @ 2008-08-19 19:08 UTC (permalink / raw) To: Rajendra Nayak Cc: linux-omap, sakari.poussa, igor.stoppa, tony, r-woodruff2, sawant, jouni.hogander Hello Rajendra, here are a few more comments on the CPUIdle patch set. Many of these, we discussed today. A closer look at patch 11/11 reveals that it will need some additional attention. - Paul General ------- 1. Please separate the context save/restore patches from the CPUIdle patches, and submit the context save/restore patches as an initial patchset, then the CPUIdle patches as a second set. 2. Also, split the cache associativity changes to arch/arm/mach-omap2/sleep34xx.S into a separate patch, and give it a descriptive commit message to help readers understand what is changing here. Comments on the context save/restore patches -------------------------------------------- 3. On the patch 5/11 "scratchpad contents," please save/restore the scratchpad registers into a structure with descriptively-named fields rather than simply incrementing a pointer across a buffer. This will document the layout of the scratchpad area and make this code easier to verify. 4. Also on the same patch, move the clear_scratchpad_contents() and save_scratchpad_contents() to mach-omap2/control.c. Please rename these functions to omap3_clear_scratchpad_contents() and omap3_save_scratchpad_contents(). 5. On patch 11/11 "CORE context save/restore," please use a structure with descriptively-named fields in place of "prcm_sleep_save", as was done for the "intc_context" and "control_ctx" structures in the same patch, and similar to comment #3 above. 6. Also on the same patch, this patch should be split into several smaller patches. The PRCM, INTC, SRAM, and SCM save/restore functions should all be split into separate patches. Please cc Paul Mundt <lethal@linux-sh.org> on the INTC patch. Also please split the serial driver clock control patch into a separate patch. 7. In the new PRCM save/restore patch, please move omap3_save_prcm_ctx() and omap3_restore_prcm_ctx() to mach-omap2/prcm.c. 8. In the new IRQ save/restore patch, please move omap_save_intc_ctx() and omap_restore_intc_ctx() to mach-omap2/irq.c. 9. In the new SCM save/restore patch, please move omap_save_control_ctx() and omap_restore_control_ctx() to mach-omap2/control.c. 10. In the following changes to omap3_pm_init() in pm34xx.c hunk: + pwrdm_add_wkdep(neon_pwrdm, mpu_pwrdm); + pwrdm_add_wkdep(per_pwrdm, core_pwrdm); + please add a comment between the two pwrdm_add_wkdep() functions, reading something similar to: /* * REVISIT: This wkdep is only necessary when GPIO2-6 are enabled for * IO-pad wakeup. Otherwise it will unnecessarily waste power * waking up PER with every CORE wakeup - see * http://marc.info/?l=linux-omap&m=121852150710062&w=2 */ 11. In omap_(save|restore)_intc_ctx(), please use intc_bank_(read|write)_reg() instead of __omap_readl/writel(). 12. In omap_save_core_context(), please use descriptive preprocessor macros for the constants in these two lines, so someone reading the code can clearly see what bits are being used without having to consult the TRM: + control_padconf_off |= 2; ... + while (!omap_readl(CONTROL_GENERAL_PURPOSE_STATUS) & 0x1); 13. Similarly, in the new serial driver patch, please use descriptive preprocessor macros for the constants in lines like these: + tmp = (serial_in(up, UART_OMAP_SYSC) & 0x7) | (1 << 3); 14. In omap3_enter_idle_bm(), the first branch of this conditional needs to have braces around it per CodingStyle chapter 2. + if (dev->safe_state) + return dev->safe_state->enter(dev, dev->safe_state); + else { 15. All of these constants from cpuidle34xx.h should be moved into driver-specific files as implied by comments #7-9 above. You should be able to delete many of them, since they already exist. But whichever constants remain (if any) should be expressed as register offsets from the OMAP device base address, not absolute addresses: +/* Interrupt Controller registers */ +#define INTC_BASE 0x48200000 +#define INTC_MIR_0 0x48200084 +#define INTC_MIR_1 0x482000A4 +#define INTC_MIR_2 0x482000C4 +#define INTCPS_SYSCONFIG 0x48200010 +#define INTCPS_PROTECTION 0x4820004C +#define INTCPS_IDLE 0x48200050 +#define INTCPS_THRESHOLD 0x48200068 + +#define CONTROL_PADCONF_SYS_NIRQ 0x480021E0 +#define CONTROL_PADCONF_OFF 0x48002270 +#define CONTROL_GENERAL_PURPOSE_STATUS 0x480022F4 + +#define OMAP34XX_GPIO1_IRQENABLE1 0x4831001c +#define OMAP34XX_GPIO1_WAKEUPEN 0x48310020 +#define OMAP34XX_GPIO1_FALLINGDETECT 0x4831004c Comments on the CPUIdle patches ------------------------------- 16. Please drop the generic drivers/cpuidle/Kconfig patch from this set, since it will affect other trees, and send it upstream separately to linux-pm, lkml, and cc Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> and Len Brown <len.brown@intel.com> for them to merge. 17. As we discussed, there are some drivers which don't work yet with OFF mode unless unmergeable workarounds are present. This is only a problem with C6, correct? Or does it also apply to the CORE CSWR states? Please wrap the affected states with #ifdefs, controlled by a new OMAP-specific Kconfig option, CONFIG_CPUIDLE_CORE_OFF_MODE or something similar. This will also need to adjust OMAP3_MAX_STATES. The option should default to disabled. When enabled, this should allow driver authors to determine whether their drivers work with OFF mode. ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2008-08-19 19:08 UTC | newest]
Thread overview: 38+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-01 14:16 [PATCH 00/11] OMAP3 CPUidle patches Rajendra Nayak
2008-07-02 13:11 ` Peter 'p2' De Schrijver
2008-07-02 13:37 ` Rajendra Nayak
2008-07-02 15:42 ` Peter 'p2' De Schrijver
2008-07-03 8:39 ` Rajendra Nayak
2008-07-03 12:44 ` Peter 'p2' De Schrijver
2008-07-04 7:26 ` Högander Jouni
2008-07-04 9:32 ` Högander Jouni
2008-07-04 9:45 ` Koen Kooi
2008-07-04 9:45 ` Rajendra Nayak
2008-07-04 9:55 ` Högander Jouni
2008-07-04 11:08 ` Högander Jouni
2008-07-07 9:38 ` Kalle Jokiniemi
2008-07-07 9:56 ` Högander Jouni
2008-07-07 13:58 ` Premi, Sanjeev
2008-07-07 22:25 ` Woodruff, Richard
2008-07-08 6:15 ` Högander Jouni
2008-07-08 12:11 ` Woodruff, Richard
2008-07-08 13:41 ` Högander Jouni
2008-07-08 13:52 ` Woodruff, Richard
2008-07-09 6:48 ` Högander Jouni
2008-07-09 16:31 ` Woodruff, Richard
2008-07-04 11:05 ` Peter 'p2' De Schrijver
2008-07-04 11:39 ` Peter 'p2' De Schrijver
2008-07-03 5:57 ` Högander Jouni
2008-07-03 10:20 ` Rajendra Nayak
2008-07-15 13:20 ` Rajendra Nayak
2008-07-18 13:18 ` [PATCH 00/11] OMAP3 CPUidle patches - ver 2 Rajendra Nayak
[not found] ` <002f01c8f7c5$0790fea0$LocalHost@wipultra1382>
2008-08-06 13:12 ` Rajendra Nayak
2008-08-07 9:54 ` Kalle Jokiniemi
2008-08-12 12:40 ` Högander Jouni
2008-08-13 5:57 ` Rajendra Nayak
2008-08-13 6:06 ` Rajendra Nayak
2008-08-13 6:55 ` Högander Jouni
2008-08-13 12:35 ` Woodruff, Richard
2008-08-13 13:12 ` Högander Jouni
2008-08-14 5:25 ` Rajendra Nayak
2008-08-19 19:08 ` Paul Walmsley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox