Re: [PATCH v3] i2c: omap: Add calls for pinctrl state select
Sekhar Nori, any objections on that version? On 28.04.2015 13:19, pascal.hue...@gmail.com wrote: From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. If no sleep state is provided in the DT, these calls turn to NOPs, so we don't need error checking here. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] omap: i2c: Add calls for pinctrl state select
On 23.04.2015 02:32, Nishanth Menon wrote: few nitpicks: i2c: omap: in $subject instead of omap: i2c: I usually would do: git log --no-merges --oneline drivers/i2c/busses/i2c-omap.c and look for common usage. Aargh, thanks for pointing that out, I'll fix that. On 04/22/2015 04:07 AM, pascal.hue...@gmail.com wrote: From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_20x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } +pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); +pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 Build tested with omap2plus_defconfig on linus master (27cf3a16b253) and next-20150422 While I do understand that the sleep state and default states are optional - might be nice to state it in commit message (as a result of which we dont do error checks). Thanks for testing. I'll fix the commit message and send in v3. Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. I'm not sure about that. Actually this is all handled by the pinctrl subsystem, so I would guess that documentation belongs there, since in: Documentation/devicetree/bindings/i2c/i2c-at91.txt Documentation/devicetree/bindings/i2c/i2c-nomadik.txt is no documentation about that as well. But there is documentation in: Documentation/pinctrl.txt right? Otherwise, I would say we should add documentation for all devices, so it is consistent. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] i2c: omap: Add calls for pinctrl state select
From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. If no sleep state is provided in the DT, these calls turn to NOPs, so we don't need error checking here. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: i2c: Add calls for pinctrl state select
On 22.04.2015 12:28, Wolfram Sang wrote: I assume you have a different kernel config where something is enabled which includes the pinctrl-stuff in another include which is included by these drivers. Although, my .config was arm-allyesconfig. Can you send yours? Sure. See below. cat .config | grep -v # | sed '/^$/d' | sort (Or do you prefer it attached?) CONFIG_ADVISE_SYSCALLS=y CONFIG_AEABI=y CONFIG_AIO=y CONFIG_ALIGNMENT_TRAP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_AM335X_CONTROL_USB=y CONFIG_AM335X_PHY_USB=y CONFIG_ANON_INODES=y CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y CONFIG_ARCH_HAS_SG_CHAIN=y CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V6_V7=y CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_NR_GPIO=0 CONFIG_ARCH_OMAP2PLUS_TYPICAL=y CONFIG_ARCH_OMAP2PLUS=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_ARM_AMBA=y CONFIG_ARM_CPU_SUSPEND=y CONFIG_ARM_DMA_MEM_BUFFERABLE=y CONFIG_ARM_ERRATA_430973=y CONFIG_ARM_ERRATA_720789=y CONFIG_ARM_GIC=y CONFIG_ARM_GLOBAL_TIMER=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_ARM_L1_CACHE_SHIFT=6 CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_ARM_THUMBEE=y CONFIG_ARM_THUMB=y CONFIG_ARM_TIMER_SP804=y CONFIG_ARM_UNWIND=y CONFIG_ARM_VIRT_EXT=y CONFIG_ARM=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_AT803X_PHY=y CONFIG_ATAGS_PROC=y CONFIG_ATAGS=y CONFIG_AUTO_ZRELADDR=y CONFIG_AVERAGE=y CONFIG_BASE_SMALL=1 CONFIG_BCH=y CONFIG_BCMA_POSSIBLE=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_BINFMT_SCRIPT=y CONFIG_BITREVERSE=y CONFIG_BLK_DEV_BSGLIB=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=8 CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV=y CONFIG_BLOCK=y CONFIG_BOUNCE=y CONFIG_BPF=y CONFIG_BQL=y CONFIG_BROKEN_ON_SMP=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BUG=y CONFIG_BUILD_BIN2C=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_CC_STACKPROTECTOR_NONE=y CONFIG_CFG80211_DEBUGFS=y CONFIG_CFG80211_DEFAULT_PS=y CONFIG_CFG80211_WEXT=y CONFIG_CFG80211=y CONFIG_CGROUPS=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLK_SP810=y CONFIG_CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK=y CONFIG_CLKSRC_MMIO=y CONFIG_CLKSRC_OF=y CONFIG_CLKSRC_VERSATILE=y CONFIG_CLK_VEXPRESS_OSC=y CONFIG_CLONE_BACKWARDS=y CONFIG_CMDLINE= CONFIG_COMMON_CLK_SI5351=y CONFIG_COMMON_CLK_VERSATILE=y CONFIG_COMMON_CLK=y CONFIG_COMPAT_BRK=y CONFIG_CONFIGFS_FS=y CONFIG_CONNECTOR=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y CONFIG_COREDUMP=y CONFIG_CPU_32v6K=y CONFIG_CPU_32v7=y CONFIG_CPU_ABRT_EV7=y CONFIG_CPU_CACHE_V7=y CONFIG_CPU_CACHE_VIPT=y CONFIG_CPU_COPY_V6=y CONFIG_CPU_CP15_MMU=y CONFIG_CPU_CP15=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ=y CONFIG_CPU_HAS_ASID=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_CPU_IDLE=y CONFIG_CPU_PABRT_V7=y CONFIG_CPU_PM=y CONFIG_CPU_TLB_V7=y CONFIG_CPU_V7=y CONFIG_CRAMFS=y CONFIG_CRC16=y CONFIG_CRC32_SLICEBY8=y CONFIG_CRC32=y CONFIG_CRC7=y CONFIG_CRC_CCITT=y CONFIG_CRC_ITU_T=y CONFIG_CRC_T10DIF=y CONFIG_CROSS_COMPILE= CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_LZO=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=y CONFIG_CRYPTO_PCOMP2=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO=y CONFIG_DCACHE_WORD_ACCESS=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_GPIO=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_LL_INCLUDE=mach/debug-macro.S CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_SECTION_MISMATCH=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_CUBIC=y CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_DEFAULT_IOSCHED=cfq CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_DEFAULT_SECURITY= CONFIG_DEFAULT_SECURITY_DAC=y
Re: [PATCH] omap: i2c: Add calls for pinctrl state select
Hey Wolfram, On 22.04.2015 10:12, Wolfram Sang wrote: On Fri, Apr 17, 2015 at 05:07:57PM +0200, pascal.hue...@gmail.com wrote: From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com ? Don't you get a build error? I do. Rightfully, I'd think, there is no pinctrl-include. You are right, the include is missing. I just reapplied the patch, compiled and interestingly enough, I don't get any compile errors. (?) Some further checks revealed, that the include is also missing in drivers/i2c/busses/i2c-st.c - which I used to get the idea on how to use these calls. I'm using a buildroot toolchain: gcc version 4.9.2 (Buildroot 2014.11-00023-g60d7a19-dirty) Do you have any idea on where these differences are coming from? In any case, the include belongs there, so I will resend that patch. regards pascal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap: i2c: Add calls for pinctrl state select
From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: i2c: Add calls for pinctrl state select
From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..6b5d4bd 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1423,6 +1423,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1433,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: i2c: Add calls for pinctrl state select
From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. --- drivers/i2c/busses/i2c-omap.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..6b5d4bd 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1423,6 +1423,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1433,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gpio-omap: wakeup mask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09.07.2014 17:24, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140709 05:47]:
On 09.07.2014 12:41, Tony Lindgren wrote:
If you just comment out the _gpio_rmw part above do things work
as expected?
Yes. It only wakes up on gpio 6 not on gpio 11 anymore.
Then if that works as expected, maybe write only some unused
bits into wkup_en register and see if it still wakes to all
events while it should not?
If I use the following testcode, everything works as expected:
//WARN(true, WARN: bank-base = %08X\n, bank-base);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
//_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
writel(0xABC0, base + bank-regs-wkup_en);
bank-context.wake_en = readl_relaxed(bank-base +
bank-regs-wkup_en); printk(bank-base = %08X gpio = %i
bank-context-wake_en = %08X\n, bank-base, gpio,
bank-context.wake_en); }
Hmm weird. It sounds like something like the following is
happening:
1. The first GPIO bank is always powered, and does not need to set
wake-up events
I dont think so. If I apply my hack (commenting the _gpio_rmw() call)
and don't have a wakeup source in the dt, I have to reboot the system,
sonce im not able to wake it up anymore. Or did I miss something?
2. When setting the GPIO wake-up events it seems that enabling any
wake-up event for the first (16?) bits wakes up the system
You might want to check this with some spare GPIOs not in the first
bank and see if you need the wake-up events and if enabling some
bits enables more than one GPIO for wake-up events.
Im not sure if this makes sense, since only the first gpio bank can
act as a wakeup source. So it should not be possible.
thanks!
pascal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlPFLEYACgkQo7eFcXQQ8U1NcACbBzQiKoU5MO/MLSdrjeg5CaAc
YJcAn3bSthD4ByFOQ31jjOFI1F/HP4Lr
=o4r2
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gpio-omap: wakeup mask
Hey Tony, all
On 04.07.2014 09:27, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140702 05:12]:
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
label = Power;
gpios = gpio0 6 1;
linux,code = 116;
gpio-key,wakeup;
};
one {
label = One;
gpios = gpio0 11 1;
linux,code = 2;
};
: : :
}
The problem is, that the device wakes up on any trigger on bank 0. No
matter which button was pressed. gpio-key,wakeup seems not to have any
influence.
Now, if I comment the following lines out in drivers/gpio/gpio-omap.c :
set_gpio_trigger(...).
321
322 if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
323_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
324 bank-context.wake_en =
325readl_relaxed(bank-base + bank-regs-wkup_en);
326 }
327
Everything works as expected. But I don't really understand why? Is this
a bug, or does this break something else I have not discovered yet?
The GPIO wake-up events are working from off-idle for omap3
the last time I checked, so sounds like this is some am335x
related issue.
Ok, that sounds reasonable.
What does your bank-context.wake_en mask get set to with this code?
by calling 'echo mem /sys/power/state' followed by a wakeup, I get the
following:
[ 28.738416] PM: Syncing filesystems ... done.
[ 28.779153] Freezing user space processes ... (elapsed 0.003 seconds)
done.
[ 28.790236] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 28.801386] PM: Sending message for entering DeepSleep mode
[ 28.935412] bank-context-wake_en = 00080840
[ 28.945935] PM: suspend of devices complete after 133.156 msecs
[ 28.961008] PM: late suspend of devices complete after 8.834 msecs
[ 28.978874] omap_hwmod: cpgmac0: _wait_target_disable failed
[ 28.985940] PM: noirq suspend of devices complete after 18.324 msecs
[ 28.992697] PM: GFX domain entered low power state
[ 28.992697] PM: Could not transition all powerdomains to target state
[ 28.992697] PM: Wakeup source GPIO0
[ 28.992866] bank-context-wake_en = 00080040
[ 29.020974] PM: noirq resume of devices complete after 22.439 msecs
[ 29.028257] bank-context-wake_en = 00080040
[ 29.032840] bank-context-wake_en = 00080840
[ 29.039207] bank-context-wake_en = 00080840
[ 29.043961] bank-context-wake_en = F200
[ 29.048534] bank-context-wake_en = F200
[ 29.053093] bank-context-wake_en = F200
[ 29.057704] bank-context-wake_en = F200
[ 29.062266] bank-context-wake_en = F200
[ 29.066992] bank-context-wake_en = 0006
[ 29.071554] bank-context-wake_en = 0006
[ 29.082499] PM: early resume of devices complete after 6.136 msecs
[ 29.091048] net eth0: initializing cpsw version 1.12 (0)
[ 29.173888] net eth0: phy found : id is : 0x4dd076
[ 29.229388] mmc0: error -110 during resume (card was removed?)
[ 29.235609] dpm_run_callback(): mmc_bus_resume+0x0/0x74 returns -110
[ 29.242272] PM: Device mmc0:0001 failed to resume: error -110
[ 29.293992] PM: resume of devices complete after 204.891 msecs
[ 29.306801] PM: Sending message for resetting M3 state machine
[ 29.313693] Restarting tasks ... done.
Thanks
Pascal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gpio-omap: wakeup mask
On 09.07.2014 12:41, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140709 03:18]:
Hey Tony, all
On 04.07.2014 09:27, Tony Lindgren wrote:
* Pascal Huerst pascal.hue...@gmail.com [140702 05:12]:
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
label = Power;
gpios = gpio0 6 1;
linux,code = 116;
gpio-key,wakeup;
};
one {
label = One;
gpios = gpio0 11 1;
linux,code = 2;
};
: : :
}
The problem is, that the device wakes up on any trigger on bank 0. No
matter which button was pressed. gpio-key,wakeup seems not to have any
influence.
Now, if I comment the following lines out in drivers/gpio/gpio-omap.c :
set_gpio_trigger(...).
321
322 if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
323_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
324 bank-context.wake_en =
325readl_relaxed(bank-base + bank-regs-wkup_en);
326 }
327
Everything works as expected. But I don't really understand why? Is this
a bug, or does this break something else I have not discovered yet?
The GPIO wake-up events are working from off-idle for omap3
the last time I checked, so sounds like this is some am335x
related issue.
Ok, that sounds reasonable.
What does your bank-context.wake_en mask get set to with this code?
by calling 'echo mem /sys/power/state' followed by a wakeup, I get the
following:
[ 28.992866] bank-context-wake_en = 00080040
[ 29.020974] PM: noirq resume of devices complete after 22.439 msecs
I guess that's for gpio bank 0 with no bit 11 as your dts has it
configured.
Yes that's right. I forgot to print the context, too. If I do so, it's:
[ 31.034972] bank-base = F9E07000 gpio = 6 bank-context-wake_en =
00080040
respectively:
[ 31.846992] bank-base = F9E07000 gpio = 11 bank-context-wake_en =
00080040
If you just comment out the _gpio_rmw part above do
things work as expected?
Yes. It only wakes up on gpio 6 not on gpio 11 anymore.
Then if that works as expected, maybe write only some unused bits
into wkup_en register and see if it still wakes to all events while
it should not?
If I use the following testcode, everything works as expected:
//WARN(true, WARN: bank-base = %08X\n, bank-base);
if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
//_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
writel(0xABC0, base + bank-regs-wkup_en);
bank-context.wake_en = readl_relaxed(bank-base +
bank-regs-wkup_en);
printk(bank-base = %08X gpio = %i bank-context-wake_en = %08X\n,
bank-base, gpio, bank-context.wake_en);
}
This produces the following output:
[ 35.319228] PM: Syncing filesystems ... done.
[ 35.358702] Freezing user space processes ... (elapsed 0.003 seconds)
done.
[ 35.369754] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 35.380734] PM: Sending message for entering DeepSleep mode
[ 35.515932] bank-base = F9E07000 gpio = 19 bank-context-wake_en =
ABC0
[ 35.529319] PM: suspend of devices complete after 137.218 msecs
[ 35.544410] PM: late suspend of devices complete after 8.715 msecs
[ 35.562247] omap_hwmod: cpgmac0: _wait_target_disable failed
[ 35.569325] PM: noirq suspend of devices complete after 18.289 msecs
[ 35.576156] PM: GFX domain entered low power state
[ 35.576156] PM: Could not transition all powerdomains to target state
[ 35.576156] PM: Wakeup source GPIO0
[ 35.576156] PM Wakeup source extra: 0840
[ 35.576329] bank-base = F9E07000 gpio = 6 bank-context-wake_en =
ABC0
[ 35.583710] bank-base = F9E07000 gpio = 11 bank-context-wake_en =
ABC0
[ 35.614846] PM: noirq resume of devices complete after 22.582 msecs
[ 35.622009] bank-base = F9E07000 gpio = 6 bank-context-wake_en =
ABC0
[ 35.631798] bank-base = F9E07000 gpio = 11 bank-context-wake_en =
ABC0
[ 35.639511] bank-base = F9E07000 gpio = 19 bank-context-wake_en =
ABC0
[ 35.647116] bank-base = FA04C000 gpio = 9 bank-context-wake_en =
ABC0
[ 35.654547] bank-base = FA04C000 gpio = 12 bank-context-wake_en =
ABC0
[ 35.662015] bank-base = FA04C000 gpio = 13 bank-context-wake_en =
ABC0
[ 35.669526] bank-base = FA04C000 gpio = 14 bank-context-wake_en =
ABC0
[ 35.677039] bank-base = FA04C000 gpio = 15 bank-context-wake_en =
ABC0
[ 35.685035] bank-base = FA1AC000 gpio = 17 bank-context-wake_en =
ABC0
[ 35.692507] bank-base = FA1AC000 gpio = 18 bank-context-wake_en =
ABC0
[ 35.706466] PM: early resume of devices complete after 6.235 msecs
[ 35.715010] net eth0: initializing cpsw version 1.12 (0)
[ 35.794388] net eth0
gpio-omap: wakeup mask
Hi everyone,
we have a device with an am335x and are using some gpios on bank0 to
wake up the device from suspend to ram.
We have some user buttons which are configured in the devicetree as
gpio-keys and one power-key which should wake up the device:
buttons {
power {
label = Power;
gpios = gpio0 6 1;
linux,code = 116;
gpio-key,wakeup;
};
one {
label = One;
gpios = gpio0 11 1;
linux,code = 2;
};
: : :
}
The problem is, that the device wakes up on any trigger on bank 0. No
matter which button was pressed. gpio-key,wakeup seems not to have any
influence.
Now, if I comment the following lines out in drivers/gpio/gpio-omap.c :
set_gpio_trigger(...).
321
322 if (likely(!(bank-non_wakeup_gpios gpio_bit))) {
323_gpio_rmw(base, bank-regs-wkup_en, gpio_bit, trigger != 0);
324 bank-context.wake_en =
325readl_relaxed(bank-base + bank-regs-wkup_en);
326 }
327
Everything works as expected. But I don't really understand why? Is this
a bug, or does this break something else I have not discovered yet?
Thanks,
Pascal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
