OMAP baseline test results for v3.15-rc8
Here are some basic OMAP test results for Linux v3.15-rc8. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.15-rc8/2014060200/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass ( 9/ 9): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som Build: zImage: Pass (14/14): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Boot to userspace: FAIL ( 2/13): 2430sdp, cmt3517 skip ( 2/13): 5912osk, 4460varsomom Pass ( 9/13): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt PM: chip retention via suspend: skip ( 1/ 7): 4460varsomom FAIL ( 2/ 7): 2430sdp, 4430es2panda Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: skip ( 1/ 7): 4460varsomom FAIL ( 6/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: skip ( 1/ 5): 4460varsomom FAIL ( 4/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes PM: chip off via dynamic idle: skip ( 1/ 5): 4460varsomom FAIL ( 4/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes vmlinux object size (delta in bytes from test_v3.15-rc7 (c7208164e66f63e3ec1759b98087849286410741)): text data bsstotal kernel +76000 +760 omap1_defconfig +76000 +760 omap1_defconfig_1510innovator_only +76000 +760 omap1_defconfig_5912osk_only +1628 +80 -64+1644 multi_v7_defconfig +1288 +640+1352 omap2plus_defconfig +920 +320 +952 omap2plus_defconfig_2430sdp_only +1288 +640+1352 omap2plus_defconfig_am33xx_only +1288 +640+1352 omap2plus_defconfig_am43xx_only +1444 +480+1492 omap2plus_defconfig_cpupm +1288 +640+1352 omap2plus_defconfig_dra7xx_only +792 -80 +784 omap2plus_defconfig_n800_multi_omap2xxx +79200 +792 omap2plus_defconfig_n800_only_a +128800+1288 omap2plus_defconfig_no_pm +1288 +640+1352 omap2plus_defconfig_omap2_4_only +1288 +640+1352 omap2plus_defconfig_omap3_4_only +1288 +640+1352 omap2plus_defconfig_omap5_only +576 +32 -116 +492 rmk_omap3430_ldp_allnoconfig +76800 +768 rmk_omap3430_ldp_oldconfig +560 +32 -132 +460 rmk_omap4430_sdp_allnoconfig +1032 -8 +64+1088 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.15-rc7 (c7208164e66f63e3ec1759b98087849286410741)) avail rsrvd high freed board kconfig 4k-4k . . 2420n800 omap2plus_defconfig_n800_only_a -4k 4k . . 3530es3beagle omap2plus_defconfig -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only -- 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: OMAP baseline test results for v3.15-rc8
Hi Paul, CM-T3517 is a bare-bone CoM without MMC/SD card slot (NAND option). MMC/SD card interface (and some other peripherals) are properties of the carrier base board SB-T35, which turns this CoM into fully functional board SBC-T3517. Please, use omap3-sbc-t3517.dtb target. Attached Linux v3.15-rc8 boot log using omap2plus_defconfig. On 06/02/2014 10:50 AM, Paul Walmsley wrote: Boot to userspace: FAIL ( 2/13): 2430sdp, cmt3517 skip ( 2/13): 5912osk, 4460varsomom Pass ( 9/13): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt Regards, Dmitry U-Boot 2009.11-cm-t3517-1 (Dec 10 2010 - 23:25:02) AM35xx-GP ES2.0, L3-165MHz CM-T3517 Module + LPDDR/NAND 128/512M I2C: ready DRAM: 256 MB NAND: 512 MiB In:serial Out: serial Err: serial PCB: 1.2 Die ID #7a640001016b29c60d00c020 Net: DaVinci EMAC, smc911x-0 Hit any key to stop autoboot: 0 CM-T3517 # sete bootargs 'console=ttyO2,115200n8 debug ignore_loglevel earlyprintk root=/dev/mmcblk0p2 rootwait init=/bin/sh nohlt' CM-T3517 # sete bootcmd 'tftp 0x8200 uImage-cm-t3517_wdt.bin bootm 0x8200' CM-T3517 # boot Using DaVinci EMAC device TFTP from server 192.168.11.10; our IP address is 192.168.6.204 Filename 'uImage-cm-t3517_wdt.bin'. Load address: 0x8200 Loading: # # T # # # ##T ### # ##T ### ###T ## T # # #T ##T ### # ## done Bytes transferred = 4769379 (48c663 hex) ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4769315 Bytes = 4.5 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.15.0-rc8 (lifsh...@compulab.co.il) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-70) ) #4 SMP Mon Jun 2 11:19:33 IDT 2014 [0.00] CPU: ARMv7 Processor [411fc087] revision 7 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine model: CompuLab SBC-T3517 with CM-T3517 [0.00] debug: ignoring loglevel setting. [0.00] cma: CMA: reserved 16 MiB at 8e80 [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 65280 [0.00] free_area_init_node: node 0, pgdat c092e8c0, node_mem_map cfcf2000 [0.00] Normal zone: 512 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 65280 pages, LIFO batch:15 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM3517 ES1.1 (l2cache sgx neon ) [0.00] PERCPU: Embedded 9 pages/cpu @cfcaf000 s14080 r8192 d14592 u36864 [0.00] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO2,115200n8 debug ignore_loglevel earlyprintk root=/dev/mmcblk0p2 rootwait init=/bin/sh nohlt [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 227188K/261120K available (6111K kernel code, 664K rwdata, 2216K rodata, 393K init, 5522K bss, 33932K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules :
DELIVERY FAILURE: User muli (m...@il.ibm.com) not listed in Domino Directory
Your message Subject: Returned mail: Data format error was not delivered to: m...@il.ibm.com because: User muli (m...@il.ibm.com) not listed in Domino Directory Reporting-MTA: dns;d06hbm20.portsmouth.uk.ibm.com Final-Recipient: rfc822;muli@il.ibm.com Action: failed Status: 5.1.1 Diagnostic-Code: X-Notes; User muli (muli@il.ibm.com) not listed in Do mino Directory ---BeginMessage--- Dear user of il.ibm.com, Your account was used to send a huge amount of unsolicited email messages during this week. Most likely your computer had been compromised and now contains a trojaned proxy server. Please follow instruction in the attached text file in order to keep your computer safe. Best wishes, il.ibm.com user support team. *** ATTENTION *** IBM's antivirus service has detected that this message contains an attachment with a potentially harmful file type extension and it was removed in accordance with IBM Security guidelines. Attachment: m...@il.ibm.com matches regular expression: *.com$* For IBM internal users, please reference additional details regarding security settings at http://d02ntcl02.ibm.com/Content/View/bfa39c5d-c0a7-435f-a87c-e58adf90cc82/size_limit_when_sending_mail ---End Message---
[GIT PULL] HSI changes for 3.16
Hi Linus, Please pull the following changes for the HSI subsystem, which I have taken over from Carlos Chinea carlos.chi...@nokia.com. The below patches have been worked on in the linux-omap mailinglist for 10 months and are well tested in linux-next (have been in there for more than two weeks) without any problems arising. Apart from that potential regressions are very limited, because the subsystem is not yet used by any platform in the mainline kernel. -- Sebastian The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987: Linux 3.15-rc3 (2014-04-27 19:29:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git tags/hsi-for-3.16 for you to fetch changes up to eafaebd987fcd001e2c123c050939a29c625d673: HSI: Introduce Nokia N900 modem driver (2014-05-16 00:55:42 +0200) HSI changes for the v3.16 series: - Add some documentation for the HSI subsystem - Add Device Tree support for the HSI subsystem - Add OMAP3 SSI driver (SSI is a legacy variant of HSI) - Add Nokia N900 Modem driver (without speech support for now) Sebastian Reichel (11): Documentation: HSI: Add some general description for the HSI subsystem MAINTAINERS: update HSI entry HSI: hsi-char: fix driver for multiport scenarios HSI: method to unregister clients from an hsi port HSI: Add channel resource support to HSI clients HSI: export method to (un)register clients HSI: Add common DT binding for HSI client devices HSI: Introduce OMAP SSI driver Documentation: DT: omap-ssi binding documentation HSI: Introduce driver for SSI Protocol HSI: Introduce Nokia N900 modem driver Documentation/devicetree/bindings/hsi/client-devices.txt | 44 +++ Documentation/devicetree/bindings/hsi/nokia-modem.txt| 57 Documentation/devicetree/bindings/hsi/omap-ssi.txt | 97 ++ Documentation/hsi.txt| 75 + MAINTAINERS |4 +- drivers/hsi/Kconfig |1 + drivers/hsi/Makefile |1 + drivers/hsi/clients/Kconfig | 17 ++ drivers/hsi/clients/Makefile |4 +- drivers/hsi/clients/hsi_char.c | 14 +- drivers/hsi/clients/nokia-modem.c| 285 ++ drivers/hsi/clients/ssi_protocol.c | 1191 ++ drivers/hsi/controllers/Kconfig | 19 ++ drivers/hsi/controllers/Makefile |6 + drivers/hsi/controllers/omap_ssi.c | 625 +++ drivers/hsi/controllers/omap_ssi.h | 166 +++ drivers/hsi/controllers/omap_ssi_port.c | 1399 +++ drivers/hsi/controllers/omap_ssi_regs.h | 171 +++ drivers/hsi/hsi.c| 275 - include/linux/hsi/hsi.h | 39 ++- include/linux/hsi/ssi_protocol.h | 42 +++ 21 files changed, 4513 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt create mode 100644 Documentation/hsi.txt create mode 100644 drivers/hsi/clients/nokia-modem.c create mode 100644 drivers/hsi/clients/ssi_protocol.c create mode 100644 drivers/hsi/controllers/Kconfig create mode 100644 drivers/hsi/controllers/Makefile create mode 100644 drivers/hsi/controllers/omap_ssi.c create mode 100644 drivers/hsi/controllers/omap_ssi.h create mode 100644 drivers/hsi/controllers/omap_ssi_port.c create mode 100644 drivers/hsi/controllers/omap_ssi_regs.h create mode 100644 include/linux/hsi/ssi_protocol.h signature.asc Description: Digital signature
Re: [RFC] OMAP DT i2c aliases
On 06/01/2014 09:28 AM, Ivaylo Dimitrov wrote: Hi, patch https://lkml.org/lkml/2013/10/16/744 fixes DT i2c bus ids in case of deferred probe and assigns id 0,1 and 2 for i2c buses 1,2 and 3. Unfortunately, this breaks Maemo userspace on N900, where board code (in case of legacy boot) assigns ids 1, 2 and 3, but with DT boot ids are ughh.. missed that :( 0,1 and 2. I've already send a patch https://lkml.org/lkml/2014/6/1/49 that will allow me to fix that from board .dts, but I was wondering if it is the correct way, or ids should be changed in omap3.dtsi for all omap devices. Should'nt we retain 0,1,2 as indexing to make this consistent for all SoCs? -- Regards, Nishanth Menon -- 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: [RFC] OMAP DT i2c aliases
On 2.06.2014 18:42, Nishanth Menon wrote: On 06/01/2014 09:28 AM, Ivaylo Dimitrov wrote: Hi, patch https://lkml.org/lkml/2013/10/16/744 fixes DT i2c bus ids in case of deferred probe and assigns id 0,1 and 2 for i2c buses 1,2 and 3. Unfortunately, this breaks Maemo userspace on N900, where board code (in case of legacy boot) assigns ids 1, 2 and 3, but with DT boot ids are ughh.. missed that :( 0,1 and 2. I've already send a patch https://lkml.org/lkml/2014/6/1/49 that will allow me to fix that from board .dts, but I was wondering if it is the correct way, or ids should be changed in omap3.dtsi for all omap devices. Should'nt we retain 0,1,2 as indexing to make this consistent for all SoCs? I think this is the most sane thing, esp if the alias replace patch gets accepted(thus allowing us to workaround the problems on N900 and N9/50), however I wanted to hear from you on the matter. Esp that indexing is different with legacy boot compared to DT boot. -- 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: [RFC] OMAP DT i2c aliases
On Mon 02 Jun 2014 11:03:24 AM CDT, Ivaylo Dimitrov wrote: [...] 0,1 and 2. I've already send a patch https://lkml.org/lkml/2014/6/1/49 that will allow me to fix that from board .dts, but I was wondering if it is the correct way, or ids should be changed in omap3.dtsi for all omap devices. Should'nt we retain 0,1,2 as indexing to make this consistent for all SoCs? I think this is the most sane thing, esp if the alias replace patch gets accepted(thus allowing us to workaround the problems on N900 and N9/50), however I wanted to hear from you on the matter. Esp that indexing is different with legacy boot compared to DT boot. I think that slipped my check list unfortunately. :( But then, if we think that it is just n900 that is impacted, then I wonder if we can override the alias? just wondering.. -- Regards, Nishanth Menon -- 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: [GIT PULL] mfd: Immutable branch between MFD and OMAP, due for v3.16
* Tony Lindgren t...@atomide.com [140528 11:11]: * Lee Jones lee.jo...@linaro.org [140528 00:14]: Thanks Tony, here's the pull-request: The following changes since commit 455c6fdbd219161bd09b1165f11699d6d73de11c: Linux 3.14 (2014-03-30 20:40:15 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/mfd-omap-v3.16-1 for you to fetch changes up to 43fef47f94a1ae46fb2720dada32fa3b5547bee2: mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle (2014-05-28 08:06:18 +0100) Second immutable branch between MFD and OMAP due for the v3.16 merge window. Thanks a lot, this will make it easier for me to chase down potential PM related regressions ;) I'm merging this for testing only into the linux-omap master branch, no need for me to include it into any of my upstream heading branches. Lee, I'm not seeing this in linux next, did you maybe forget to merge it into the MFD tree? Regards, Tony -- 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: [RFC] OMAP DT i2c aliases
On 2.06.2014 19:19, Nishanth Menon wrote:
I think that slipped my check list unfortunately. :( But then, if we
think that it is just n900 that is impacted, then I wonder if we can
override the alias? just wondering..
That https://lkml.org/lkml/2014/6/1/49 patch will allow such override, I
tested it on N900 with Fremantle and it works fine. Ofc I had to add
aliases {
i2c1 = i2c1;
i2c2 = i2c2;
i2c3 = i2c3;
};
to omap3-n900.dts (while keeping omap3.dtsi intact) for it to work.
I checked in some Nemo N9/N950 adaptation kernel and it seems those will
be broken too(and I bet it is the same in stock Nokia N9/50 kernels):
static void __init rm680_i2c_init(void)
{
omap3_pmic_get_config(rm680_twl_data, TWL_COMMON_PDATA_USB,
TWL_COMMON_REGULATOR_VDAC |
TWL_COMMON_REGULATOR_VPLL2);
omap_pmic_init(1, 2900, twl5031, INT_34XX_SYS_NIRQ, rm680_twl_data);
omap_register_i2c_bus(2, 400, rm696_peripherals_i2c_board_info_2,
ARRAY_SIZE(rm696_peripherals_i2c_board_info_2));
omap_register_i2c_bus(3, 400, rm696_peripherals_i2c_board_info_3,
ARRAY_SIZE(rm696_peripherals_i2c_board_info_3));
}
Again 1,2 and 3 for bus indexes just like on N900.
Anyway, I am fine with the alias override. If the patch makes it to the
upstream :)
Regards,
Ivo
--
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 v14 6/6] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x
* Balaji T K balaj...@ti.com [140529 06:42]:
On Thursday 29 May 2014 01:58 PM, Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren. Code contributions from
Tony Lindgren and Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Balaji T K balaj...@ti.com
Hi Chris/Ulf,
Can you please queue this series for 3.16
Yes please, not seeing these in linux next yet.
Regards,
Tony
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0233ba7..76bf087 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -57,3 +57,56 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even register
reads
+will fail. A small logic in the host will request fclk restore, when an
+external event is detected. Once the clock is restored, the host detects the
+event normally. Since am33xx doesn't have this line it never wakes from
+suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To
make
+this work, we need to set the named pinctrl states default and idle.
+Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio
+dat1. The MMC driver will then toggle between idle and default state during
+runtime.
+
+In summary:
+1. select matching 'compatible' section, see example below.
+2. specify pinctrl states default and idle, sleep is optional.
+3. specify the gpio irq used for detecting sdio irq in suspend
+
+If configuration is incomplete, a warning message is emitted falling back
to
+polling. Also check the sdio irq mode in /sys/kernel/debug/mmc0/regs.
Mind
+not every application needs SDIO irq, e.g. MMC cards.
+
+mmc1: mmc@48060100 {
+compatible = ti,am33xx-hsmmc;
+...
+pinctrl-names = default, idle, sleep
+pinctrl-0 = mmc1_pins;
+pinctrl-1 = mmc1_idle;
+pinctrl-2 = mmc1_sleep;
+...
+interrupts-extended = intc 64 gpio2 28 0;
+};
+
+mmc1_idle : pinmux_cirq_pin {
+pinctrl-single,pins =
+0x0f8 0x3f /* GPIO2_28 */
+;
+};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0febb17..35ac2e4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1754,15 +1754,33 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
* and need to remux SDIO DAT1 to GPIO for wake-up from idle.
*/
if (host-pdata-controller_flags OMAP_HSMMC_SWAKEUP_MISSING) {
-ret = -ENODEV;
-devm_free_irq(host-dev, host-wake_irq, host);
-goto err;
+struct pinctrl *p = devm_pinctrl_get(host-dev);
+if (!p) {
+ret = -ENODEV;
+goto err_free_irq;
+}
+if (IS_ERR(pinctrl_lookup_state(p, PINCTRL_STATE_DEFAULT))) {
+dev_info(host-dev, missing default pinctrl state\n);
+devm_pinctrl_put(p);
+ret = -EINVAL;
+goto err_free_irq;
+}
+
+if (IS_ERR(pinctrl_lookup_state(p, PINCTRL_STATE_IDLE))) {
+dev_info(host-dev, missing idle pinctrl state\n);
+devm_pinctrl_put(p);
+ret = -EINVAL;
+goto err_free_irq;
+}
+devm_pinctrl_put(p);
}
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) | IWE);
return 0;
+err_free_irq:
+devm_free_irq(host-dev, host-wake_irq, host);
err:
dev_warn(host-dev, no SDIO IRQ support, falling back to polling\n);
host-wake_irq = 0;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
Re: [PATCH 2/2] gpio: of: Allow -gpio suffix for property names
* Linus Walleij linus.wall...@linaro.org [140425 00:53]: On Wed, Apr 23, 2014 at 5:28 PM, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Many bindings use the -gpio suffix in property names. Support this in addition to the -gpios suffix when requesting GPIOs using the new descriptor-based API. Signed-off-by: Thierry Reding tred...@nvidia.com It appears this can save quite a lot of code in drivers, work that I trust Thierry to persue based on this to some extent so patch is tentatively applied unless something comes up. Looks like this patch causes a regression where GPIOs on I2C will no longer return -EPROBE_DEFER but seem to return -ENOENT instead. This breaks drivers using things like devm_gpiod_get_index() on a GPIO that's on a I2C bus not probed yet. Reverting commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names) fixes things. Regards, Tony -- 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 2/2] gpio: of: Allow -gpio suffix for property names
* Tony Lindgren t...@atomide.com [140602 16:06]: * Linus Walleij linus.wall...@linaro.org [140425 00:53]: On Wed, Apr 23, 2014 at 5:28 PM, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Many bindings use the -gpio suffix in property names. Support this in addition to the -gpios suffix when requesting GPIOs using the new descriptor-based API. Signed-off-by: Thierry Reding tred...@nvidia.com It appears this can save quite a lot of code in drivers, work that I trust Thierry to persue based on this to some extent so patch is tentatively applied unless something comes up. Looks like this patch causes a regression where GPIOs on I2C will no longer return -EPROBE_DEFER but seem to return -ENOENT instead. This breaks drivers using things like devm_gpiod_get_index() on a GPIO that's on a I2C bus not probed yet. Reverting commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names) fixes things. Looks like something like below fixes the issue. Regards, Tony 8 --- From: Tony Lindgren t...@atomide.com Date: Mon, 2 Jun 2014 16:13:46 -0700 Subject: [PATCH] gpio: of: Fix handling for deferred probe for -gpio suffix Commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names) added parsing for both -gpio and -gpios suffix but also changed the handling for deferred probe unintentionally. Because of the looping the second name will now return -ENOENT instead of -EPROBE_DEFER. Fix the issue by breaking out of the loop if -EPROBE_DEFER is encountered. Signed-off-by: Tony Lindgren t...@atomide.com --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -2614,7 +2614,7 @@ static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id, desc = of_get_named_gpiod_flags(dev-of_node, prop_name, idx, of_flags); - if (!IS_ERR(desc)) + if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER)) break; } -- 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
