Re: [PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi, On Fri, Dec 06, 2013 at 02:15:30PM -0600, Felipe Balbi wrote: On Tue, Dec 03, 2013 at 12:39:50PM +0200, Heikki Krogerus wrote: On Thu, Oct 17, 2013 at 09:54:26AM -0500, Felipe Balbi wrote: On Wed, Oct 16, 2013 at 04:27:26PM +0300, Roger Quadros wrote: On 10/16/2013 04:10 PM, Kishon Vijay Abraham I wrote: Do you know if there are users of dwc3 other than exynos5250 and omap5? If not, we should get rid of the old USB PHY altogether. Intel's Baytrail, at least. But they don't use DT. I don't see any use for the generic-phy when the device is enumerated from PCI. If dwc3 can live without phys, there should not be any problem dropping the old USB PHY support. yeah, I don't want to drop PHY support, I want to require everybody to provide a PHY, otherwise we have too many options to handle and that's never clean. I have to clarify in case there was a misunderstanding. When I said generic-phy I meant drivers/usb/phy/phy-generic.c and I was not talking about Kishon's new generic PHY framework. So I was only saying that if the dwc3-pci.c is the only thing that needs the old usb phy support, then there should not be any problem dropping the support for it. Thanks, -- heikki -- 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 v3 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi, On Mon, Dec 09, 2013 at 12:43:37PM +0530, Kishon Vijay Abraham I wrote: On Thursday 05 December 2013 01:28 PM, Heikki Krogerus wrote: On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote: On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote: There can be systems which does not have an external phy, so get phy only if no quirks are added that indicates the PHY is not present. Introduced two quirk flags to indicate the *absence* of usb2 phy and usb3 phy. Also remove checking if return value is -ENXIO since it's now changed to always enable usb_phy layer. Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other right. but that doesn't consider broken dt data. With quirks we'll able to tell if a controller in a particular platform has PHY or not without depending on the dt data. Broken dt data? What kind of scenario are you thinking here? Do you mean case where the dt does not describe the phy on a platform that depends on it? Shouldn't that problem be fixed in the dt and not hacked in the drivers? Or are you thinking about something else? Is there a case where something like that is actually happening? Br, -- heikki -- 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 1/1] drivers: net : cpsw: Use netdev_name while requesting irq
On Saturday 07 December 2013 02:16 AM, David Miller wrote: From: Mugunthan V N mugunthan...@ti.com Date: Fri, 6 Dec 2013 12:28:27 +0530 From: George Cherian george.cher...@ti.com Use netdev_name while requesting irq so that eth* name is shown in /proc/interrupts. Previously it was showing device name as (null) for cpsw interrupts. For using netdev_name register_netdev and then call devm_request_irq. Signed-off-by: George Cherian george.cher...@ti.com Signed-off-by: Mugunthan V N mugunthan...@ti.com Why is it showing (null) as the name, is dev_name() not working properly for this device? The only change you are making is passing netdev_name() instead of dev_name(). dev_name() giving NULL doesn't make much sense to me. priv-dev is a network device which is registered to network stack after request interrupt, so dev name is null, with this patch request interrupt is moved below after registering the network device with the network Initial driver was using DT node name for the interrupts, but with the devm changes by Daniel Mack in commit 50a5fb068 it was changed to ndev name which introduced this issue. Regards Mugunthan V N -- 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 01/15] mfd: menelaus: Drop __exit section annotation
The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. example ? All of your commit messages. that macro just helps removing some extra ^- Sentences start with an uppercase character. line of code and hides ffs() calls. while at that, also fix a variable shadowing ^- Sentences start with an uppercase character. bug where 'int irq' was being redeclared inside inner loop while it was also argument to interrupt handler. --- 50 chars - Please use the full 72 char (or there abouts) width of the buffer. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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.13-rc1 (toolchain Debian 4.7.2-5)
On Mon, 25 Nov 2013, Paul Walmsley wrote: On Mon, 25 Nov 2013, Paul Walmsley wrote: Boot to userspace: FAIL ( 1/11): 37xxevm So looks like this is due to the switchover to DT-based booting for 37xx EVM. Will plug that in here and re-test. Here's the updated test report. Looks like dynamic idle PM tests are failing on the 37xxevm now. - Paul OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5) Here are some basic OMAP test results for Linux v3.13-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc1/20131208173326/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, 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 Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Boot to userspace: skip ( 1/ 1): 5912osk Pass (11/11): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.12 (5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52)): text data bsstotal kernel -351659 +384+4216 -347059 omap1_defconfig -354695 +296+4216 -350183 omap1_defconfig_1510innovator_only -354491 +360+4216 -349915 omap1_defconfig_5912osk_only -276029-5584+5008 -276605 omap2plus_defconfig -292693+9808+4656 -278229 omap2plus_defconfig_2430sdp_only -273194-5512+5008 -273698 omap2plus_defconfig_cpupm +88436 +10392+4368 +103196 omap2plus_defconfig_n800_multi_omap2xxx +88404 +10408+4368 +103180 omap2plus_defconfig_n800_only_a -273765-4704+5008 -273461 omap2plus_defconfig_no_pm -263629 +13912+4944 -244773 omap2plus_defconfig_omap2_4_only -270645-5584+5008 -271221 omap2plus_defconfig_omap3_4_only -119724 -10124+2960 -126888 rmk_omap3430_ldp_allnoconfig +49719+3936+4352 +58007 rmk_omap3430_ldp_oldconfig -115704+1788+5608 -108308 rmk_omap4430_sdp_allnoconfig +4738404 +250480 +443152 +5432036 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.12 (5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52)) avail rsrvd high freed board kconfig -104k 104k . 4k 2420n800 omap2plus_defconfig_n800_only_a 276k -276k .-8k 2430sdpomap2plus_defconfig 276k -276k .-8k 3517evmomap2plus_defconfig 276k -276k .-8k 3530es3beagle omap2plus_defconfig 276k -276k .-8k 3730beaglexm omap2plus_defconfig 228k -228k .-8k 37xxevmomap2plus_defconfig 272k -272k .-8k 4430es2panda omap2plus_defconfig 268k -268k .-8k 4460pandaesomap2plus_defconfig 272k -272k .-8k 4460varsomom omap2plus_defconfig 312k -312k . 4k am335xbone omap2plus_defconfig_am33xx_only 268k -268k .-8k am335xbonelt omap2plus_defconfig -- 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
OMAP baseline test results for v3.13-rc2
Here are some basic OMAP test results for Linux v3.13-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc2/20131208173520/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, 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 Boot to userspace: skip ( 1/ 1): 5912osk Pass (11/11): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.13-rc1 (6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae)): text data bsstotal kernel +620 +160 +636 omap1_defconfig +652 +240 +676 omap1_defconfig_1510innovator_only +620 -80 +612 omap1_defconfig_5912osk_only +8904 +192 +64+9160 omap2plus_defconfig +4624 -320+4592 omap2plus_defconfig_2430sdp_only +4808 +128 +128+5064 omap2plus_defconfig_cpupm +556 -32 +32 +556 omap2plus_defconfig_n800_multi_omap2xxx +4652 +8 +32+4692 omap2plus_defconfig_n800_only_a +4808 +128 +64+5000 omap2plus_defconfig_no_pm +4120 +640+4184 omap2plus_defconfig_omap2_4_only +4808 +200 +64+5072 omap2plus_defconfig_omap3_4_only +1648 +108 -788 +968 rmk_omap3430_ldp_allnoconfig +1184 +128 +64+1376 rmk_omap3430_ldp_oldconfig +208 +52 -412 -152 rmk_omap4430_sdp_allnoconfig +2692 -4 +64+2752 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.13-rc1 (6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae)) avail rsrvd high freed board kconfig -8k 8k . . 2430sdpomap2plus_defconfig -8k 8k . . 3517evmomap2plus_defconfig -8k 8k . . 3530es3beagle omap2plus_defconfig -8k 8k . . 3730beaglexm omap2plus_defconfig -8k 8k . . 37xxevmomap2plus_defconfig -8k 8k . . 4430es2panda omap2plus_defconfig -8k 8k . . 4460pandaesomap2plus_defconfig -8k 8k . . 4460varsomom omap2plus_defconfig -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only -8k 8k . . am335xbonelt omap2plus_defconfig -- 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
OMAP baseline test results for v3.13-rc3
Here are some basic OMAP test results for Linux v3.13-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc3/20131208173612/ Test summary Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, 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 Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Boot to userspace: skip ( 1/ 1): 5912osk Pass (11/11): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.13-rc2 (dc1ccc48159d63eca5089e507c82c7d22ef60839)): text data bsstotal kernel +37600 +376 omap1_defconfig +33200 +332 omap1_defconfig_1510innovator_only +136800+1368 omap1_defconfig_5912osk_only +448+18160+2264 omap2plus_defconfig +44+19520+1996 omap2plus_defconfig_2430sdp_only +520+17840+2304 omap2plus_defconfig_cpupm +4372 +160+4388 omap2plus_defconfig_n800_multi_omap2xxx +308 -160 +292 omap2plus_defconfig_n800_only_a +320+18160+2136 omap2plus_defconfig_no_pm +448+18160+2264 omap2plus_defconfig_omap2_4_only +448+17840+2232 omap2plus_defconfig_omap3_4_only +416 +16 -156 +276 rmk_omap3430_ldp_allnoconfig +176 +160 +192 rmk_omap3430_ldp_oldconfig +280 -16 -116 +148 rmk_omap4430_sdp_allnoconfig +256 +8960+1152 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.13-rc2 (dc1ccc48159d63eca5089e507c82c7d22ef60839)) avail rsrvd high freed board kconfig -4k 4k . . 4460varsomom omap2plus_defconfig -4k 4k . . 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: [RFC/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
On Sun, Dec 8, 2013 at 5:40 AM, Chao Xu caesarxuc...@gmail.com wrote: From: Felipe Balbi ba...@ti.com try to keep gpio block suspended as much as possible. Tested with pandaboard and a sysfs exported gpio. Signed-off-by: Felipe Balbi balbi at ti.com [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision check to enable aggressive pm_runtime on OMAP4-only. Because am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. Tested on Pandaboard rev A2.] Signed-off-by: Chao Xu caesarxuc...@gmail.com Kevin/Santosh: you're maintainers for this driver, can you ACK/NACK this patch? Yours, Linus Walleij -- 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: OMAP3 NAND ECC selection
Le Mon, 9 Dec 2013 04:33:51 +, Gupta, Pekon pe...@ti.com a écrit : Hi, From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: [...] Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Just to highlight few more points: (1) ROM code on newer OMAP platforms like AM33xx do have the ability to select ECC scheme by reading a specific location from EEPROM connected to I2C0. AFAIK on omap3, the rom code first try to read data with bch and if it doesn't work it fallback on haming 1 bit ecc. (2) And going forward, ECC based NAND devices may be phased out, and BE-NAND (Built-in) NAND devices are becoming popular. As both cost and density wise they are same to SLC NANDs today. Thus issue of un-compatibility of ecc-scheme with ROM code, will not hold true. We already have some BE-NAND support in our generic driver. http://patchwork.ozlabs.org/patch/222186/ Yes but these flash are not always compatible with the ROM. If the rom is expecting some ECC and the internal controller expect other ecc you are stuck. Matthieu -- 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 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi Kishon, On Mon, Dec 9, 2013 at 7:07 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Saturday 07 December 2013 02:38 AM, Felipe Balbi wrote: Hi, On Fri, Dec 06, 2013 at 01:14:38PM +0100, Javier Martinez Canillas wrote: On Fri, Dec 6, 2013 at 1:06 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the device name of the controller had *.auto* in it. Since with using PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance, the data given in usb_bind_phy became obsolete and usb_get_phy was failing. So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding change is done in board file here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- 12 files changed, 12 insertions(+), 12 deletions(-) You can drop this patch since boards files are being removed for v3.14 if we can drop this patch, the whole series is invalid, since we'll be using DT phandles to find PHYs going forward, no ? yeah. But in one of the other threads, Tony seemed ok to take a patch that fixes the same issue in mach-omap2/twl-common.c. So it's better to confirm with Tony. Yes, I just read the other thread ([PATCH] omap: twl-common: Fix musb-hdrc device name) and I see that these patches are fixing a v3.13 regression and are meant for the -rc cycle and not for v3.14. Sorry for the noise then. Best regards, Javier Thanks Kishon -- 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: OMAP3 NAND ECC selection
From: Matthieu CASTET [mailto:matthieu.cas...@parrot.com] From: Pekon Gupta [mailto: pe...@ti.com] From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: [...] Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Just to highlight few more points: (1) ROM code on newer OMAP platforms like AM33xx do have the ability to select ECC scheme by reading a specific location from EEPROM connected to I2C0. AFAIK on omap3, the rom code first try to read data with bch and if it doesn't work it fallback on haming 1 bit ecc. I'm afraid, the OMAP35xx TRM does give much information about BCH ecc-scheme being used by ROM code. Though it says that BCH4 ecc-scheme would be selected for booting in cases when NAND_ID2 matches a particular value. But nothing much is clear (Reference [1]). Can you please point me to any other document or link which gives more info about the same ? (2) And going forward, ECC based NAND devices may be phased out, and BE-NAND (Built-in) NAND devices are becoming popular. As both cost and density wise they are same to SLC NANDs today. Thus issue of un-compatibility of ecc-scheme with ROM code, will not hold true. We already have some BE-NAND support in our generic driver. http://patchwork.ozlabs.org/patch/222186/ Yes but these flash are not always compatible with the ROM. If the rom is expecting some ECC and the internal controller expect other ecc you are stuck. For AM33xx and newer DRA7xx platforms, allows user to explicitly select between no ECC, BCH8 or BCH16. Thus ROM code of newer OMAP devices supports BE-NAND. (refer [2]). [1] http://www.ti.com/product/omap3530 http://www.ti.com/litv/pdf/spruf98x Chapter 25: Initialization Section 25.4.7.4 NAND Table 25-34. ID2 Byte Description [2] http://www.ti.com/product/am3359 http://www.ti.com/litv/pdf/spruh73i Chapter 26: Initialization Section: 26.1.7.4 Memory Booting NAND Table 26-17. NAND Geometry Information on I2C EEPROM with regards, pekon -- 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
Problem with a hih6130 sensor in a OMAP I2C bus
Hi, While testing an HIH6130 humidity and temperature sensor with I2C interface in a BeagleBone board I've found that I was unable to read it because the driver always returned EINVAL. With some debugging I've found that the error was due to a test on omap_i2c_xfer_msg() in OMAP I2C driver that invalidates zero length writes. The hwmon hih6130 driver issues such kind of request in hih6130_update_measurements() to issue a measurement request to the sensor. I was able to get measurements from the sensor by hacking the hih6130 driver replacing the following line in hih6130_update_measurements(); ret = i2c_master_send(client, tmp, 0); by tmp[0] = 0; ret = i2c_master_send(client, tmp, 1); Is this the correct way to fix this issue, or should the fix be in the I2C OMAP driver to accept zero length transfers? Best regards, José Gonçalves -- 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 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-07 06:28, Javier Martinez Canillas wrote:
Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the
right
thing for legacy platform data probing but no for DT probing:
static int dvic_probe_pdata(struct platform_device *pdev)
{
..
adapter = i2c_get_adapter(i2c_bus_num);
if (!adapter) {
dev_err(pdev-dev,
Failed to get I2C adapter, bus %d\n,
i2c_bus_num);
return -EPROBE_DEFER;
}
..
}
static int dvic_probe_of(struct platform_device *pdev)
{
..
adapter = of_find_i2c_adapter_by_node(adapter_node);
if (adapter == NULL) {
dev_err(pdev-dev, failed to parse i2c-bus\n);
omap_dss_put_device(ddata-in);
return -EINVAL;
}
..
}
The following patch solves the issue if you want to include in your patch-set:
Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
On 2013-12-06 10:41, Javier Martinez Canillas wrote:
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 67
++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aaacc68..1ca1932d02aa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -178,3 +178,70 @@
mode = 3;
power = 50;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+venc {
+ vdda_dac-supply = vdac;
+
+ venc_out: endpoint {
+ remote-endpoint = tv_connector_in;
+ };
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio5 10 0; /* 170, power-down */
+
Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
from 1 so gpio5 + 10 is GPIO 138.
Yes, you're right. Good catch.
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint =
dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = ti,dvi_connector;
+ i2c-bus = i2c3;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+
+ tv0: connector@1 {
+ compatible = ti,svideo_connector;
+
+ tv_connector_in: endpoint {
+ remote-endpoint = venc_out;
+ };
+ };
+};
--
1.8.3.2
Also I don't see the DSS pinmux set for this board. I guess you need
something like the following on top:
0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
True. I need to add something like this to all the dts files.
You didn't have muxing in the omap3-igep0020 patch you gave. Is the
muxing already set in some other patch?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
Hi Tomi,
On Mon, Dec 9, 2013 at 1:06 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-06 10:41, Javier Martinez Canillas wrote:
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 67
++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aaacc68..1ca1932d02aa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -178,3 +178,70 @@
mode = 3;
power = 50;
};
+
+dpi {
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+venc {
+ vdda_dac-supply = vdac;
+
+ venc_out: endpoint {
+ remote-endpoint = tv_connector_in;
+ };
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio5 10 0; /* 170, power-down */
+
Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
from 1 so gpio5 + 10 is GPIO 138.
Yes, you're right. Good catch.
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint =
dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = ti,dvi_connector;
+ i2c-bus = i2c3;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+
+ tv0: connector@1 {
+ compatible = ti,svideo_connector;
+
+ tv_connector_in: endpoint {
+ remote-endpoint = venc_out;
+ };
+ };
+};
--
1.8.3.2
Also I don't see the DSS pinmux set for this board. I guess you need
something like the following on top:
0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
True. I need to add something like this to all the dts files.
You didn't have muxing in the omap3-igep0020 patch you gave. Is the
muxing already set in some other patch?
Your patch-set is based on v3.13-rc1 but I sent a patch-set [0] to fix
a few regressions for IGEPv2 when we moved to DT-only boot. One of
these patches added the needed DSS pinmuxing and these were included
in v3.13-rc2.
So to test your branch I cherry-picked:
d526daeb (ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices)
50592dc3 (ARM: dts: omap3-igep0020: Add pinmuxing for DVI output)
Also, for 3.13 I added a DT hack
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On Mon, Dec 9, 2013 at 1:01 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-07 06:28, Javier Martinez Canillas wrote:
Actually, I looked at drivers/video/omap2/connector-dvi.c and it does the
right
thing for legacy platform data probing but no for DT probing:
static int dvic_probe_pdata(struct platform_device *pdev)
{
..
adapter = i2c_get_adapter(i2c_bus_num);
if (!adapter) {
dev_err(pdev-dev,
Failed to get I2C adapter, bus %d\n,
i2c_bus_num);
return -EPROBE_DEFER;
}
..
}
static int dvic_probe_of(struct platform_device *pdev)
{
..
adapter = of_find_i2c_adapter_by_node(adapter_node);
if (adapter == NULL) {
dev_err(pdev-dev, failed to parse i2c-bus\n);
omap_dss_put_device(ddata-in);
return -EINVAL;
}
..
}
The following patch solves the issue if you want to include in your
patch-set:
Thanks, I'll add this and the omap3-igep0020 support to my DT branch.
Great, thanks a lot for working on this!
I'm very happy that we will have proper display support for IGEPv2 on
v3.14 without any DT hacks or pdata-quirks :-)
Tomi
Best regards,
Javier
--
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: Problem with a hih6130 sensor in a OMAP I2C bus
Hi José, On Mon, 09 Dec 2013 11:42:13 +, José Miguel Gonçalves wrote: While testing an HIH6130 humidity and temperature sensor with I2C interface in a BeagleBone board I've found that I was unable to read it because the driver always returned EINVAL. With some debugging I've found that the error was due to a test on omap_i2c_xfer_msg() in OMAP I2C driver that invalidates zero length writes. The hwmon hih6130 driver issues such kind of request in hih6130_update_measurements() to issue a measurement request to the sensor. I was able to get measurements from the sensor by hacking the hih6130 driver replacing the following line in hih6130_update_measurements(); ret = i2c_master_send(client, tmp, 0); by tmp[0] = 0; ret = i2c_master_send(client, tmp, 1); Is this the correct way to fix this issue, or should the fix be in the I2C OMAP driver to accept zero length transfers? Ideally it should be fixed in the i2c-omap bus driver. However, if zero-length transfers are explicitly prohibited, it may mean that the hardware itself can't do it (in which case adding a comment saying so in the source code would be great.) You'll have to check. The driver supports several generations of OMAP chipsets so you'll have to check them all, maybe some can handle zero-length messages and some do not. If fixing it in the i2c-omap driver is not possible, then working around it in the hih6130 driver would be acceptable. You'll have to make sure there is no side effect to sending a single byte to the chip. If performance is a concern, you may have to enable the workaround only when zero-byte messages aren't supported. You can check with: i2c_get_functionality(i2c_adapter) I2C_FUNC_SMBUS_QUICK -- Jean Delvare -- 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 13/26] ARM: omap3.dtsi: add omapdss information
On 2013-12-05 19:05, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131204 04:31]: Description missing.. But other than that can you please check that the latest patch I posted in thread [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device works with this? The test to do is to remove the related reg, interrupt and dma entries from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized from DT properly. I made a quick test with panda, by applying your patch and reverting b38911f3472be89551bfca740adf0009562b9873. That only effectively tests the DISPC IRQ, but that worked fine. I don't know if it makes sense to have them as children of dss_core, they really all seem to be completely independent devices? The DSS subdevices depend on the dss_core. dss_core has to be powered up for any of the subdevices to work. This is done automatically by the runtime PM when the subdevices are children of the dss_core. BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods property and do the lookup based on the compatible property instead ;) So from that point of view we need to get the device mapping right in the .dtsi files, and don't want to start mixing up separate devices into single .dtsi entry. Hmm, was that just a general comment, or something that affects the DSS DT data I have in my patch? As far as I understand, the DSS nodes reflect the current hwmods correctly. With the exception that DPI and SDI do not have a matching hwmod, as they are really part of dss_core/dispc. They are separate nodes as they are video outputs the same way as the other subnodes. I could perhaps remove the DPI and SDI nodes, and have them as direct video ports from DISPC, but... That's easier said than done. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio1 0 0; /* 0, power-down */
+
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = gpio1 0 GPIO_ACTIVE_HIGH; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is power-down. I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 5/8] gpio: twl4030: Fix regression for twl gpio output
On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros rog...@ti.com wrote: (...) This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2. As one of the LED GPO is used for USB host on beagleboard, it will cause failure of USB host probe. (...) Below is a proposed fix for this. Roger, Tony: what happened with this? Have you hashed this out? I ACK Roger's fixup too if that needs to be merged into the OMAP tree. Yours, Linus Walleij -- 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: Problem with a hih6130 sensor in a OMAP I2C bus
Hi Jean, On 09-12-2013 12:22, Jean Delvare wrote: Hi José, On Mon, 09 Dec 2013 11:42:13 +, José Miguel Gonçalves wrote: While testing an HIH6130 humidity and temperature sensor with I2C interface in a BeagleBone board I've found that I was unable to read it because the driver always returned EINVAL. With some debugging I've found that the error was due to a test on omap_i2c_xfer_msg() in OMAP I2C driver that invalidates zero length writes. The hwmon hih6130 driver issues such kind of request in hih6130_update_measurements() to issue a measurement request to the sensor. I was able to get measurements from the sensor by hacking the hih6130 driver replacing the following line in hih6130_update_measurements(); ret = i2c_master_send(client, tmp, 0); by tmp[0] = 0; ret = i2c_master_send(client, tmp, 1); Is this the correct way to fix this issue, or should the fix be in the I2C OMAP driver to accept zero length transfers? Ideally it should be fixed in the i2c-omap bus driver. However, if zero-length transfers are explicitly prohibited, it may mean that the hardware itself can't do it (in which case adding a comment saying so in the source code would be great.) You'll have to check. The driver supports several generations of OMAP chipsets so you'll have to check them all, maybe some can handle zero-length messages and some do not. If fixing it in the i2c-omap driver is not possible, then working around it in the hih6130 driver would be acceptable. You'll have to make sure there is no side effect to sending a single byte to the chip. If performance is a concern, you may have to enable the workaround only when zero-byte messages aren't supported. You can check with: i2c_get_functionality(i2c_adapter) I2C_FUNC_SMBUS_QUICK I am by no means an expert on OMAP platforms and/or I2C drivers so, if anyone else with more knowledge of them has a better suggestion, I will follow your suggestion and submit my workaround patch for the hih6130 driver with the added check for support of zero-byte messages by the underlying I2C driver. From my understanding of the technical note for I2C communication on this chip; http://www.mouser.com/pdfdocs/I2CCommunications.pdf I see no problems on writing that dummy byte to it and my tests on a real hardware also show that. Best regards, José Gonçalves -- 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 0/5] phy: remove the need for the phys to know about their users
Hi, This replaces the consumer init_data structures with a lookup table that contains complete associations with the phys and their users, removing the need for the phy drivers themselves to care about their users even when not using DT. The lookup method is copied from the way the gpio descriptor lookup is now handled in gpiolib.c. Heikki Krogerus (5): phy: unify the phy name parameters phy: add support for indexed lookup phy: improved lookup method arm: omap3: twl: use the new lookup method with usb phy phy: remove the old lookup method arch/arm/mach-omap2/twl-common.c| 15 ++- drivers/phy/phy-core.c | 209 ++-- drivers/phy/phy-exynos-dp-video.c | 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-twl4030-usb.c | 4 +- include/linux/phy/phy.h | 86 ++- 7 files changed, 221 insertions(+), 99 deletions(-) -- 1.8.5.1 -- 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] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
Documentation/phy.txt | 100 ++--
drivers/phy/phy-core.c | 46 ++---
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 4 +-
include/linux/phy/phy.h | 36 ++---
7 files changed, 73 insertions(+), 119 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index 0103e4b..cfff1a2 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -53,17 +53,13 @@ unregister the PHY.
The PHY driver should create the PHY in order for other peripheral controllers
to make use of it. The PHY framework provides 2 APIs to create the PHY.
-struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
-struct phy_init_data *init_data);
-struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data);
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer, phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
Inorder to dereference the private data (in phy_ops), the phy provider driver
can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
@@ -74,16 +70,21 @@ phy_ops to get back the private data.
Before the controller can make use of the PHY, it has to get a reference to
it. This framework provides the following APIs to get a reference to the PHY.
-struct phy *phy_get(struct device *dev, const char *string);
-struct phy *devm_phy_get(struct device *dev, const char *string);
+struct phy *phy_get(struct device *dev, const char *con_id);
+struct phy *devm_phy_get(struct device *dev, const char *con_id);
phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
-the string arguments should contain the phy name as given in the dt data and
+the con_id arguments should contain the phy name as given in the dt data and
in the case of non-dt boot, it should contain the label of the PHY.
The only difference between the two APIs is that devm_phy_get associates the
device with the PHY using devres on successful PHY get. On driver detach,
release function is invoked on the the devres data and devres data is freed.
+Indexed lookup is also possible when device has multiple PHYs attached to it.
+The framework provides variants for phy_get() functions called phy_get_index()
+and devm_phy_get_index(). They take the same parameters as do the normal
+phy_get() plus the index number of the PHY as the last parameter.
+
5. Releasing a reference to the PHY
When the controller no longer needs the PHY, it has to release the reference
@@ -123,42 +124,63 @@ There are exported APIs like phy_pm_runtime_get,
phy_pm_runtime_get_sync,
phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
phy_pm_runtime_forbid for performing PM operations.
-8. Board File Initialization
+8. Platform Data binding
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
+PHY's are mapped by the means of tables of lookups, containing instances of the
+phy_lookup structure. Two macros are defined to help declaring such mappings:
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
+ PHY_LOOKUP(phy_name, con_id)
+ PHY_LOOKUP_IDX(phy_name, con_id, idx)
+
+where
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+ - phy_name identifiers of the phy device
+ - con_id is the name of the PHY from the device point of view. It can be
NULL.
+ - idx is the index of the PHY within the function.
+
+A lookup table can then be defined as follows, with an empty entry defining its
+end:
+
+struct phy_lookup_table phys_table = {
+ .dev_id = usb_controller.0,
+ .table = {
+ PHY_LOOKUP_IDX(phy-usb2phy.0, usb2-phy, 0),
+
[PATCH 2/5] phy: add support for indexed lookup
Removes the need for the consumer drivers requesting the
phys to provide name for the phy. This should ease the use
of the framework considerable when using only one phy, which
is usually the case when except with USB, but it can also
be useful with multiple phys.
This will also reduce noise from the framework when there is
no phy by changing warnings to debug messages.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-core.c | 106 ++--
include/linux/phy/phy.h | 14 +++
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 1102aef..99dc046 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -53,7 +53,8 @@ static int devm_phy_match(struct device *dev, void *res, void
*match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *con_id)
+static struct phy *phy_lookup(struct device *device, const char *con_id,
+ unsigned int idx)
{
unsigned int count;
struct phy *phy;
@@ -67,6 +68,10 @@ static struct phy *phy_lookup(struct device *device, const
char *con_id)
count = phy-init_data-num_consumers;
consumers = phy-init_data-consumers;
while (count--) {
+ /* index must always match exactly */
+ if (!con_id)
+ if (idx != count)
+ continue;
if (!strcmp(consumers-dev_name, dev_name(device))
!strcmp(consumers-port, con_id)) {
class_dev_iter_exit(iter);
@@ -242,7 +247,8 @@ EXPORT_SYMBOL_GPL(phy_power_off);
/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
- * @index: the index of the phy
+ * @con_id: name of the phy from device's point of view
+ * @idx: the index of the phy if name is not used
*
* Returns the phy associated with the given phandle value,
* after getting a refcount to it or -ENODEV if there is no such phy or
@@ -250,12 +256,20 @@ EXPORT_SYMBOL_GPL(phy_power_off);
* not yet loaded. This function uses of_xlate call back function provided
* while registering the phy_provider to find the phy instance.
*/
-static struct phy *of_phy_get(struct device *dev, int index)
+static struct phy *of_phy_get(struct device *dev, const char *con_id,
+ unsigned int idx)
{
int ret;
struct phy_provider *phy_provider;
struct phy *phy = NULL;
struct of_phandle_args args;
+ int index;
+
+ if (!con_id)
+ index = idx;
+ else
+ index = of_property_match_string(dev-of_node, phy-names,
+con_id);
ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
index, args);
@@ -348,38 +362,36 @@ struct phy *of_phy_simple_xlate(struct device *dev,
struct of_phandle_args
EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
/**
- * phy_get() - lookup and obtain a reference to a phy.
+ * phy_get_index() - obtain a phy based on index
* @dev: device that requests this phy
* @con_id: name of the phy from device's point of view
+ * @idx: index of the phy to obtain in the consumer
*
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy. The caller is responsible for
- * calling phy_put() to release that count.
+ * This variant of phy_get() allows to access PHYs other than the first
+ * defined one for functions that define several PHYs.
*/
-struct phy *phy_get(struct device *dev, const char *con_id)
+struct phy *phy_get_index(struct device *dev, const char *con_id,
+ unsigned int idx)
{
- int index = 0;
struct phy *phy = NULL;
- if (con_id == NULL) {
- dev_WARN(dev, missing string\n);
- return ERR_PTR(-EINVAL);
+ if (dev-of_node) {
+ dev_dbg(dev, using device tree for PHY lookup\n);
+ phy = of_phy_get(dev, con_id, idx);
}
- if (dev-of_node) {
- index = of_property_match_string(dev-of_node, phy-names,
-con_id);
- phy = of_phy_get(dev, index);
- if (IS_ERR(phy)) {
- dev_err(dev, unable to find phy\n);
- return phy;
- }
- } else {
- phy = phy_lookup(dev, con_id);
- if (IS_ERR(phy)) {
- dev_err(dev, unable to find phy\n);
- return phy;
- }
+ /**
+* Either we are not using DT, or their lookup did not return
+* a result. In that case, use platform lookup
[PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..972430b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup_table twl4030_usb_lookup = {
+ .dev_id = musb-hdrc.0,
+ .table = PHY_LOOKUP(phy-twl4030_usb.0, NULL),
};
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
};
static int omap3_batt_table[] = {
@@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_add_lookup_table(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
1.8.5.1
--
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 3/5] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from gpiolib.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-core.c | 91 -
include/linux/phy/phy.h | 48 ++
2 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 99dc046..05792d0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -25,6 +25,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phy_lookup_list);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -85,6 +86,94 @@ static struct phy *phy_lookup(struct device *device, const
char *con_id,
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_add_table() - register PHY/device association to the lookup list
+ * @table: association to register
+ */
+void phy_add_lookup_table(struct phy_lookup_table *table)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(table-list, phy_lookup_list);
+ mutex_unlock(phy_provider_mutex);
+}
+
+/**
+ * phy_add_table() - remove PHY/device association from the lookup list
+ * @table: association to be removed
+ */
+void phy_del_lookup_table(struct phy_lookup_table *table)
+{
+ mutex_lock(phy_provider_mutex);
+ list_del(table-list);
+ mutex_unlock(phy_provider_mutex);
+}
+
+static struct phy *find_phy_by_name(const char *name)
+{
+ struct class_dev_iter iter;
+ struct phy *phy = NULL;
+ struct device *dev;
+
+ class_dev_iter_init(iter, phy_class, NULL, NULL);
+ while ((dev = class_dev_iter_next(iter))) {
+ if (!strcmp(dev_name(dev), name)) {
+ phy = to_phy(dev);
+ break;
+ }
+ }
+ class_dev_iter_exit(iter);
+
+ return phy;
+}
+
+static struct phy_lookup_table *phy_get_lookup_table(struct device *dev)
+{
+ const char *dev_id = dev ? dev_name(dev) : NULL;
+ struct phy_lookup_table *table;
+
+ mutex_lock(phy_provider_mutex);
+ list_for_each_entry(table, phy_lookup_list, list)
+ if (!strcmp(table-dev_id, dev_id))
+ goto out;
+ table = NULL;
+out:
+ mutex_unlock(phy_provider_mutex);
+ return table;
+}
+
+static struct phy *phy_find(struct device *dev, const char *con_id,
+ unsigned int idx)
+{
+ struct phy_lookup_table *table;
+ struct phy_lookup *p;
+ struct phy *phy;
+
+ table = phy_get_lookup_table(dev);
+ if (!table)
+ /* fall-back to the old lookup method for now */
+ return phy_lookup(dev, con_id, idx);
+
+ for (p = table-table[0]; p-phy_name; p++) {
+ /* index must always match exactly */
+ if (idx != p-idx)
+ continue;
+
+ /* If the lookup entry has a con_id, require exact match */
+ if (p-con_id (!con_id || strcmp(p-con_id, con_id)))
+ continue;
+
+ phy = find_phy_by_name(p-phy_name);
+ if (!phy) {
+ dev_warn(dev, no PHY by the name %s\n, p-phy_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
{
struct phy_provider *phy_provider;
@@ -386,7 +475,7 @@ struct phy *phy_get_index(struct device *dev, const char
*con_id,
*/
if (!phy || IS_ERR(phy)) {
dev_dbg(dev, using lookup tables for PHY lookup);
- phy = phy_lookup(dev, con_id, idx);
+ phy = phy_find(dev, con_id, idx);
}
if (IS_ERR(phy)) {
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 43d1a23..cca363a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -98,6 +98,54 @@ struct phy_init_data {
.port = _port,\
}
+/**
+ * struct phy_lookup - Lookup entry for associating PHYs
+ * @phy_name: device name of the PHY
+ * @con_id: name of the PHY from device's point of view
+ * @idx: index of the PHY when name is not used
+ */
+struct phy_lookup {
+ const char *phy_name;
+ const char *con_id;
+ unsigned int idx;
+};
+
+/**
+ * struct phy_lookup_table - association of PHYs to specific device
+ * @list: entry in the lookup list
+ * @dev_id: the name of the device
+ * @table: table of PHYs attached to this device
+ */
+struct phy_lookup_table {
+ struct list_head list;
+ const char *dev_id;
+ struct phy_lookup table[];
+};
+
+/**
+ * Simple definition of a single PHY under a consumer
+ */
+#define
[PATCH 1/5] phy: unify the phy name parameters
Replace string and port that are used as phy name
parameter for various functions with con_id which is
commonly used in other frameworks.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-core.c | 22 ++
include/linux/phy/phy.h | 8
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..1102aef 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -53,7 +53,7 @@ static int devm_phy_match(struct device *dev, void *res, void
*match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
+static struct phy *phy_lookup(struct device *device, const char *con_id)
{
unsigned int count;
struct phy *phy;
@@ -68,7 +68,7 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
consumers = phy-init_data-consumers;
while (count--) {
if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
+ !strcmp(consumers-port, con_id)) {
class_dev_iter_exit(iter);
return phy;
}
@@ -350,33 +350,32 @@ EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
/**
* phy_get() - lookup and obtain a reference to a phy.
* @dev: device that requests this phy
- * @string: the phy name as given in the dt data or the name of the controller
- * port for non-dt case
+ * @con_id: name of the phy from device's point of view
*
* Returns the phy driver, after getting a refcount to it; or
* -ENODEV if there is no such phy. The caller is responsible for
* calling phy_put() to release that count.
*/
-struct phy *phy_get(struct device *dev, const char *string)
+struct phy *phy_get(struct device *dev, const char *con_id)
{
int index = 0;
struct phy *phy = NULL;
- if (string == NULL) {
+ if (con_id == NULL) {
dev_WARN(dev, missing string\n);
return ERR_PTR(-EINVAL);
}
if (dev-of_node) {
index = of_property_match_string(dev-of_node, phy-names,
- string);
+con_id);
phy = of_phy_get(dev, index);
if (IS_ERR(phy)) {
dev_err(dev, unable to find phy\n);
return phy;
}
} else {
- phy = phy_lookup(dev, string);
+ phy = phy_lookup(dev, con_id);
if (IS_ERR(phy)) {
dev_err(dev, unable to find phy\n);
return phy;
@@ -395,14 +394,13 @@ EXPORT_SYMBOL_GPL(phy_get);
/**
* devm_phy_get() - lookup and obtain a reference to a phy.
* @dev: device that requests this phy
- * @string: the phy name as given in the dt data or phy device name
- * for non-dt case
+ * @con_id: name of the phy from device's point of view
*
* Gets the phy using phy_get(), and associates a device with it using
* devres. On driver detach, release function is invoked on the devres data,
* then, devres data is freed.
*/
-struct phy *devm_phy_get(struct device *dev, const char *string)
+struct phy *devm_phy_get(struct device *dev, const char *con_id)
{
struct phy **ptr, *phy;
@@ -410,7 +408,7 @@ struct phy *devm_phy_get(struct device *dev, const char
*string)
if (!ptr)
return ERR_PTR(-ENOMEM);
- phy = phy_get(dev, string);
+ phy = phy_get(dev, con_id);
if (!IS_ERR(phy)) {
*ptr = phy;
devres_add(dev, ptr);
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..d67dcbf 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -127,8 +127,8 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
-struct phy *phy_get(struct device *dev, const char *string);
-struct phy *devm_phy_get(struct device *dev, const char *string);
+struct phy *phy_get(struct device *dev, const char *con_id);
+struct phy *devm_phy_get(struct device *dev, const char *con_id);
void phy_put(struct phy *phy);
void devm_phy_put(struct device *dev, struct phy *phy);
struct phy *of_phy_simple_xlate(struct device *dev,
@@ -199,12 +199,12 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
-static inline struct phy *phy_get(struct device *dev, const char *string)
+static inline struct phy *phy_get(struct device *dev, const char *con_id)
{
return ERR_PTR(-ENOSYS);
}
-static inline struct phy *devm_phy_get(struct device *dev, const char *string)
+static inline struct phy *devm_phy_get(struct device *dev, const char *con_id)
{
return
Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio1 0 0; /* 0, power-down */
+
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = gpio1 0 GPIO_ACTIVE_HIGH; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is power-down. I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Thanks a lot and best regards,
Javier
[0]: http://www.ti.com/lit/ds/slds145b/slds145b.pdf
--
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 15/26] ARM: omap4-panda.dts: add display information
On 2013-12-09 17:09, Javier Martinez Canillas wrote:
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio1 0 0; /* 0, power-down */
+
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = gpio1 0 GPIO_ACTIVE_HIGH; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is power-down. I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
as it were active-low. The flag is ignored.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC/RFT/PATCH V3] gpio: omap: refresh patch be more aggressive with pm_runtime against v3.12-rc5
Chao Xu caesarxuc...@gmail.com writes: From: Felipe Balbi ba...@ti.com try to keep gpio block suspended as much as possible. Tested with pandaboard and a sysfs exported gpio. Signed-off-by: Felipe Balbi balbi at ti.com [caesarxuc...@gmail.com : Refreshed against v3.12-rc5, and added revision check to enable aggressive pm_runtime on OMAP4-only. Because am33xx_gpio_sysc.idlemodes seems to be wrongly marked as SIDLE_SMART_WKUP, which might cause missed interrupts with this patch. Tested on Pandaboard rev A2.] Signed-off-by: Chao Xu caesarxuc...@gmail.com I have several problems with this patch. First, the changelog is missing a lot of information. In particular, nowhere is it described what problem is this patch addressing and how this patch addresses that problem. Second, I don't see any mention of off-mode, and I suspect there are issues with off-mode here that are not being addressed. Also, I *really* don't like any approach that is targetted at a single SoC. Kevin -- 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] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
Tony Lindgren t...@atomide.com writes: * Nishanth Menon n...@ti.com [131203 17:40]: Due to the cross dependencies between hwmod for automanaged device information for OMAP and dts node definitions, we can run into scenarios where the dts node is defined, however it's hwmod entry is yet to be added. In these cases: a) omap_device does not register a pm_domain (since it cannot find hwmod entry). b) driver does not know about (a), does a pm_runtime_get_sync which never fails c) It then tries to do some operation on the device (such as read the revision register (as part of probe) without clock or adequate OMAP generic PM operation performed for enabling the module. This causes a crash such as that reported in: https://bugzilla.kernel.org/show_bug.cgi?id=66441 When 'ti,hwmod' is provided in dt node, it is expected that the device will not function without the OMAP's power automanagement. Hence, when we hit a fail condition (due to hwmod entries not present or other similar scenario), fail at pm_domain level due to lack of data, provide enough information for it to be fixed, however, it allows for the driver to take appropriate measures to prevent crash. Kevin, any comments on this one? Looks like a good approach to catch these corner cases. Acked-by: Kevin Hilman khil...@linaro.org -- 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 01/15] mfd: menelaus: Drop __exit section annotation
Hi, On Mon, Dec 09, 2013 at 09:37:48AM +, Lee Jones wrote: The code looks mostly fine, but the implementation of the commit logs seems lazy. Please submit a v3 using coherent sentences with full explanations and correct punctuation. example ? All of your commit messages. that macro just helps removing some extra ^- Sentences start with an uppercase character. line of code and hides ffs() calls. while at that, also fix a variable shadowing ^- Sentences start with an uppercase character. bug where 'int irq' was being redeclared inside inner loop while it was also argument to interrupt handler. --- 50 chars - Please use the full 72 char (or there abouts) width of the buffer. I don't see any mention of punctuation problems, however. Also, you're not complaining about the content at all, which tells me those sentences aren't as incoherent as you claimed before. But fair enough, I'll fix those up and add Aaro's Tested-by -- balbi signature.asc Description: Digital signature
[PATCH v3 15/15] mfd: menelaus: Use devm_request_threaded_irq()
By using devm_request_threaded_irq() we can drop a few extra lines of
code and rely on device managed resources layer to free our IRQ for us.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index bffe978..b87c2bd 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1271,8 +1271,8 @@ static int menelaus_probe(struct i2c_client *client,
/* Set output buffer strengths */
menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73);
- err = request_threaded_irq(client-irq, NULL, menelaus_irq,
- IRQF_ONESHOT, DRIVER_NAME, m);
+ err = devm_request_threaded_irq(client-dev, client-irq,
+ NULL, menelaus_irq, IRQF_ONESHOT, DRIVER_NAME, m);
if (err) {
dev_dbg(client-dev, can't get IRQ %d, err %d\n,
client-irq, err);
@@ -1283,7 +1283,7 @@ static int menelaus_probe(struct i2c_client *client,
val = menelaus_read_reg(m, MENELAUS_VCORE_CTRL1);
if (val 0)
- goto fail_free_irq;
+ goto fail_free_descs;
if (val (1 7))
m-vcore_hw_mode = 1;
else
@@ -1292,14 +1292,12 @@ static int menelaus_probe(struct i2c_client *client,
if (menelaus_pdata != NULL menelaus_pdata-late_init != NULL) {
err = menelaus_pdata-late_init(client-dev);
if (err 0)
- goto fail_free_irq;
+ goto fail_free_descs;
}
menelaus_rtc_init(m);
return 0;
-fail_free_irq:
- free_irq(client-irq, m);
fail_free_descs:
irq_free_descs(irq_base, MENELAUS_NR_IRQS);
@@ -1311,7 +1309,6 @@ static int menelaus_remove(struct i2c_client *client)
{
struct menelaus_chip*m = i2c_get_clientdata(client);
- free_irq(client-irq, m);
irq_free_descs(m-irq_base, MENELAUS_NR_IRQS);
the_menelaus = NULL;
return 0;
--
1.8.4.GIT
--
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 05/15] mfd: menelaus: Use for_each_set_bit()
That macro just helps removing some extra line of code and hides ffs()
calls.
While at that, also fix a variable shadowing bug where 'int irq' was
being redeclared inside inner loop while it was also argument to
interrupt handler.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 11dc4d3..9ccbb79 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,24 +795,22 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
- unsigned isr;
+ unsigned long isr;
+ unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
~menelaus-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
~menelaus-mask1;
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
+ for_each_set_bit(i, isr, 16) {
mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
+ menelaus_disable_irq(i);
+ menelaus_ack_irq(i);
+ handler = menelaus-handlers[i];
if (handler)
handler(menelaus);
- menelaus_enable_irq(irq);
+ menelaus_enable_irq(i);
mutex_unlock(menelaus-lock);
}
--
1.8.4.GIT
--
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 07/15] mfd: menelaus: Limit the usage of the_menelaus
Pass a menelaus_chip pointer as argument to most functions so we can
minimize the usage of the global the_menelaus pointer.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 265 ++---
1 file changed, 142 insertions(+), 123 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 4c51e4b..8796e5e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -177,9 +177,9 @@ struct menelaus_chip {
static struct menelaus_chip *the_menelaus;
-static int menelaus_write_reg(int reg, u8 value)
+static int menelaus_write_reg(struct menelaus_chip *m, int reg, u8 value)
{
- int val = i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
+ int val = i2c_smbus_write_byte_data(m-client, reg, value);
if (val 0) {
pr_err(DRIVER_NAME : write error);
@@ -189,9 +189,9 @@ static int menelaus_write_reg(int reg, u8 value)
return 0;
}
-static int menelaus_read_reg(int reg)
+static int menelaus_read_reg(struct menelaus_chip *m, int reg)
{
- int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
+ int val = i2c_smbus_read_byte_data(m-client, reg);
if (val 0)
pr_err(DRIVER_NAME : read error);
@@ -204,11 +204,11 @@ static int menelaus_enable_irq(struct menelaus_chip *m,
int irq)
if (irq 7) {
irq -= 8;
m-mask2 = ~(1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK2,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK2,
m-mask2);
} else {
m-mask1 = ~(1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK1,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK1,
m-mask1);
}
}
@@ -218,11 +218,11 @@ static int menelaus_disable_irq(struct menelaus_chip *m,
int irq)
if (irq 7) {
irq -= 8;
m-mask2 |= (1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK2,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK2,
m-mask2);
} else {
m-mask1 |= (1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK1,
+ return menelaus_write_reg(m, MENELAUS_INT_MASK1,
m-mask1);
}
}
@@ -230,9 +230,9 @@ static int menelaus_disable_irq(struct menelaus_chip *m,
int irq)
static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
{
if (irq 7)
- return menelaus_write_reg(MENELAUS_INT_ACK2, 1 (irq - 8));
+ return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 (irq - 8));
else
- return menelaus_write_reg(MENELAUS_INT_ACK1, 1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
}
/* Adds a handler for an interrupt. Does not run in interrupt context */
@@ -268,12 +268,12 @@ static int menelaus_remove_irq_work(int irq)
* in each slot. In this case the cards are not seen by menelaus.
* FIXME: Add handling for D1 too
*/
-static void menelaus_mmc_cd_work(struct menelaus_chip *menelaus_hw)
+static void menelaus_mmc_cd_work(struct menelaus_chip *m)
{
int reg;
unsigned char card_mask = 0;
- reg = menelaus_read_reg(MENELAUS_MCT_PIN_ST);
+ reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg 0)
return;
@@ -283,8 +283,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip
*menelaus_hw)
if (!(reg 0x2))
card_mask |= MCT_PIN_ST_S2_CD_ST;
- if (menelaus_hw-mmc_callback)
- menelaus_hw-mmc_callback(menelaus_hw-mmc_callback_data,
+ if (m-mmc_callback)
+ m-mmc_callback(m-mmc_callback_data,
card_mask);
}
@@ -293,14 +293,16 @@ static void menelaus_mmc_cd_work(struct menelaus_chip
*menelaus_hw)
*/
int menelaus_set_mmc_opendrain(int slot, int enable)
{
+ struct menelaus_chip *m = the_menelaus;
int ret, val;
if (slot != 1 slot != 2)
return -EINVAL;
- mutex_lock(the_menelaus-lock);
- ret = menelaus_read_reg(MENELAUS_MCT_CTRL1);
+
+ mutex_lock(m-lock);
+ ret = menelaus_read_reg(m, MENELAUS_MCT_CTRL1);
if (ret 0) {
- mutex_unlock(the_menelaus-lock);
+ mutex_unlock(m-lock);
return ret;
}
val = ret;
@@ -315,8 +317,8 @@ int menelaus_set_mmc_opendrain(int slot, int enable)
else
val = ~MCT_CTRL1_S2_CMD_OD;
}
- ret = menelaus_write_reg(MENELAUS_MCT_CTRL1, val);
- mutex_unlock(the_menelaus-lock);
+ ret = menelaus_write_reg(m, MENELAUS_MCT_CTRL1, val);
+ mutex_unlock(m-lock);
return ret;
}
[PATCH v3 09/15] mfd: menelaus: Pass menelaus_chip pointer to get/set voltage
Those functions are static and can easily receive a menelaus_chip
pointer argument.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 50 +++---
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8672d86..13d1cb0 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -463,10 +463,9 @@ struct menelaus_vtg_value {
u16 val;
};
-static int menelaus_set_voltage(const struct menelaus_vtg *vtg, int mV,
- int vtg_val, int mode)
+static int menelaus_set_voltage(struct menelaus_chip *m,
+ const struct menelaus_vtg *vtg, int mV, int vtg_val, int mode)
{
- struct menelaus_chip *m = the_menelaus;
struct i2c_client *c = m-client;
int val, ret;
@@ -498,8 +497,8 @@ out:
return ret;
}
-static int menelaus_get_vtg_value(int vtg, const struct menelaus_vtg_value
*tbl,
- int n)
+static int menelaus_get_vtg_value(struct menelaus_chip *m,
+ int vtg, const struct menelaus_vtg_value *tbl, int n)
{
int i;
@@ -546,7 +545,7 @@ int menelaus_set_vcore_sw(unsigned int mV)
struct i2c_client *c = m-client;
int val, ret;
- val = menelaus_get_vtg_value(mV, vcore_values,
+ val = menelaus_get_vtg_value(m, mV, vcore_values,
ARRAY_SIZE(vcore_values));
if (val 0)
return -EINVAL;
@@ -570,11 +569,11 @@ int menelaus_set_vcore_hw(unsigned int roof_mV, unsigned
int floor_mV)
struct i2c_client *c = m-client;
int fval, rval, val, ret;
- rval = menelaus_get_vtg_value(roof_mV, vcore_values,
+ rval = menelaus_get_vtg_value(m, roof_mV, vcore_values,
ARRAY_SIZE(vcore_values));
if (rval 0)
return -EINVAL;
- fval = menelaus_get_vtg_value(floor_mV, vcore_values,
+ fval = menelaus_get_vtg_value(m, floor_mV, vcore_values,
ARRAY_SIZE(vcore_values));
if (fval 0)
return -EINVAL;
@@ -619,15 +618,16 @@ static const struct menelaus_vtg_value vmem_values[] = {
int menelaus_set_vmem(unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
int val;
if (mV == 0)
- return menelaus_set_voltage(vmem_vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vmem_vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vmem_values, ARRAY_SIZE(vmem_values));
+ val = menelaus_get_vtg_value(m, mV, vmem_values,
ARRAY_SIZE(vmem_values));
if (val 0)
return -EINVAL;
- return menelaus_set_voltage(vmem_vtg, mV, val, 0x02);
+ return menelaus_set_voltage(m, vmem_vtg, mV, val, 0x02);
}
EXPORT_SYMBOL(menelaus_set_vmem);
@@ -648,15 +648,16 @@ static const struct menelaus_vtg_value vio_values[] = {
int menelaus_set_vio(unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
int val;
if (mV == 0)
- return menelaus_set_voltage(vio_vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vio_vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vio_values, ARRAY_SIZE(vio_values));
+ val = menelaus_get_vtg_value(m, mV, vio_values, ARRAY_SIZE(vio_values));
if (val 0)
return -EINVAL;
- return menelaus_set_voltage(vio_vtg, mV, val, 0x02);
+ return menelaus_set_voltage(m, vio_vtg, mV, val, 0x02);
}
EXPORT_SYMBOL(menelaus_set_vio);
@@ -689,6 +690,7 @@ static const struct menelaus_vtg vdcdc3_vtg = {
int menelaus_set_vdcdc(int dcdc, unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
const struct menelaus_vtg *vtg;
int val;
@@ -700,13 +702,13 @@ int menelaus_set_vdcdc(int dcdc, unsigned int mV)
vtg = vdcdc3_vtg;
if (mV == 0)
- return menelaus_set_voltage(vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vdcdc_values,
+ val = menelaus_get_vtg_value(m, mV, vdcdc_values,
ARRAY_SIZE(vdcdc_values));
if (val 0)
return -EINVAL;
- return menelaus_set_voltage(vtg, mV, val, 0x03);
+ return menelaus_set_voltage(m, vtg, mV, val, 0x03);
}
static const struct menelaus_vtg_value vmmc_values[] = {
@@ -726,15 +728,16 @@ static const struct menelaus_vtg vmmc_vtg = {
int menelaus_set_vmmc(unsigned int mV)
{
+ struct menelaus_chip *m = the_menelaus;
int val;
if (mV == 0)
- return menelaus_set_voltage(vmmc_vtg, 0, 0, 0);
+ return menelaus_set_voltage(m, vmmc_vtg, 0, 0, 0);
- val = menelaus_get_vtg_value(mV, vmmc_values,
[PATCH v3 08/15] mfd: menelaus: Pass menelaus_chip pointer to add/remove irq functions
Those functions are static and can receive a menelaus_chip pointer very
easily.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 57 ++
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8796e5e..8672d86 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -236,28 +236,28 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int
irq)
}
/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(int irq,
+static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
{
int ret = 0;
- mutex_lock(the_menelaus-lock);
- the_menelaus-handlers[irq] = handler;
- ret = menelaus_enable_irq(the_menelaus, irq);
- mutex_unlock(the_menelaus-lock);
+ mutex_lock(m-lock);
+ m-handlers[irq] = handler;
+ ret = menelaus_enable_irq(m, irq);
+ mutex_unlock(m-lock);
return ret;
}
/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(int irq)
+static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
{
int ret = 0;
- mutex_lock(the_menelaus-lock);
- ret = menelaus_disable_irq(the_menelaus, irq);
- the_menelaus-handlers[irq] = NULL;
- mutex_unlock(the_menelaus-lock);
+ mutex_lock(m-lock);
+ ret = menelaus_disable_irq(m, irq);
+ m-handlers[irq] = NULL;
+ mutex_unlock(m-lock);
return ret;
}
@@ -412,23 +412,24 @@ EXPORT_SYMBOL(menelaus_set_mmc_slot);
int menelaus_register_mmc_callback(void (*callback)(void *data, u8 card_mask),
void *data)
{
+ struct menelaus_chip *m = the_menelaus;
int ret = 0;
- the_menelaus-mmc_callback_data = data;
- the_menelaus-mmc_callback = callback;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S1CD_IRQ,
+ m-mmc_callback_data = data;
+ m-mmc_callback = callback;
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
menelaus_mmc_cd_work);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S2CD_IRQ,
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
menelaus_mmc_cd_work);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S1D1_IRQ,
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
menelaus_mmc_cd_work);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(MENELAUS_MMC_S2D1_IRQ,
+ ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2D1_IRQ,
menelaus_mmc_cd_work);
return ret;
@@ -437,13 +438,15 @@ EXPORT_SYMBOL(menelaus_register_mmc_callback);
void menelaus_unregister_mmc_callback(void)
{
- menelaus_remove_irq_work(MENELAUS_MMC_S1CD_IRQ);
- menelaus_remove_irq_work(MENELAUS_MMC_S2CD_IRQ);
- menelaus_remove_irq_work(MENELAUS_MMC_S1D1_IRQ);
- menelaus_remove_irq_work(MENELAUS_MMC_S2D1_IRQ);
+ struct menelaus_chip *m = the_menelaus;
+
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S1CD_IRQ);
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S2CD_IRQ);
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S1D1_IRQ);
+ menelaus_remove_irq_work(m, MENELAUS_MMC_S2D1_IRQ);
- the_menelaus-mmc_callback = NULL;
- the_menelaus-mmc_callback_data = NULL;
+ m-mmc_callback = NULL;
+ m-mmc_callback_data = NULL;
}
EXPORT_SYMBOL(menelaus_unregister_mmc_callback);
@@ -1070,8 +1073,8 @@ static int menelaus_ioctl(struct device *dev, unsigned
cmd, unsigned long arg)
case RTC_UIE_ON:
if (m-uie)
return 0;
- status = menelaus_remove_irq_work(MENELAUS_RTCTMR_IRQ);
- status = menelaus_add_irq_work(MENELAUS_RTCTMR_IRQ,
+ status = menelaus_remove_irq_work(m, MENELAUS_RTCTMR_IRQ);
+ status = menelaus_add_irq_work(m, MENELAUS_RTCTMR_IRQ,
menelaus_rtc_update_work);
if (status == 0)
m-uie = 1;
@@ -1079,7 +1082,7 @@ static int menelaus_ioctl(struct device *dev, unsigned
cmd, unsigned long arg)
case RTC_UIE_OFF:
if (!m-uie)
return 0;
- status = menelaus_remove_irq_work(MENELAUS_RTCTMR_IRQ);
+ status = menelaus_remove_irq_work(m, MENELAUS_RTCTMR_IRQ);
if (status == 0)
m-uie = 0;
return status;
@@ -1127,7 +1130,7 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
/* support RTC alarm; it can
[PATCH v3 10/15] mfd: menelaus: Pass menelaus_chip argument to menelaus - time helpers
time_to_menelaus() and menelaus_to_time() are static and can easily
receive a struct menelaus_chip pointer argument.
After this patch, the_menelaus is only used on exported functions which
are currently being used by board-n8x0.c.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 13d1cb0..aa3c579 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -857,10 +857,9 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
#define RTC_HR_PM (1 7)
-static void menelaus_to_time(char *regs, struct rtc_time *t)
+static void menelaus_to_time(struct menelaus_chip *m,
+ char *regs, struct rtc_time *t)
{
- struct menelaus_chip *m = the_menelaus;
-
t-tm_sec = bcd2bin(regs[0]);
t-tm_min = bcd2bin(regs[1]);
if (m-rtc_control RTC_CTRL_MODE12) {
@@ -874,9 +873,9 @@ static void menelaus_to_time(char *regs, struct rtc_time *t)
t-tm_year = bcd2bin(regs[5]) + 100;
}
-static int time_to_menelaus(struct rtc_time *t, int regnum)
+static int time_to_menelaus(struct menelaus_chip *m,
+ struct rtc_time *t, int regnum)
{
- struct menelaus_chip *m = the_menelaus;
int hour, status;
status = menelaus_write_reg(m, regnum++, bin2bcd(t-tm_sec));
@@ -944,7 +943,7 @@ static int menelaus_read_time(struct device *dev, struct
rtc_time *t)
return -EIO;
}
- menelaus_to_time(regs, t);
+ menelaus_to_time(m, regs, t);
t-tm_wday = bcd2bin(regs[6]);
return 0;
@@ -956,7 +955,7 @@ static int menelaus_set_time(struct device *dev, struct
rtc_time *t)
int status;
/* write date and time registers */
- status = time_to_menelaus(t, MENELAUS_RTC_SEC);
+ status = time_to_menelaus(m, t, MENELAUS_RTC_SEC);
if (status 0)
return status;
status = menelaus_write_reg(m, MENELAUS_RTC_WKDAY, bin2bcd(t-tm_wday));
@@ -1001,7 +1000,7 @@ static int menelaus_read_alarm(struct device *dev, struct
rtc_wkalrm *w)
return -EIO;
}
- menelaus_to_time(regs, w-time);
+ menelaus_to_time(m, regs, w-time);
w-enabled = !!(m-rtc_control RTC_CTRL_AL_EN);
@@ -1029,7 +1028,7 @@ static int menelaus_set_alarm(struct device *dev, struct
rtc_wkalrm *w)
}
/* write alarm registers */
- status = time_to_menelaus(w-time, MENELAUS_RTC_AL_SEC);
+ status = time_to_menelaus(m, w-time, MENELAUS_RTC_AL_SEC);
if (status 0)
return status;
--
1.8.4.GIT
--
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 12/15] mfd: menelaus: Switch all children to threaded_irq
Now that we have our own irq_chip, all children can use traditional
request_threaded_irq().
While at that, also remove so functions which became unused.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 161 +++--
1 file changed, 50 insertions(+), 111 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index e4f33b7..74eae19 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -175,7 +175,6 @@ struct menelaus_chip {
u8 mask1, mask2;
u8 ack1, ack2;
- void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
@@ -209,42 +208,6 @@ static int menelaus_read_reg(struct menelaus_chip *m, int
reg)
return val;
}
-static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7) {
- irq -= 8;
- m-mask2 = ~(1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK2,
- m-mask2);
- } else {
- m-mask1 = ~(1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK1,
- m-mask1);
- }
-}
-
-static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7) {
- irq -= 8;
- m-mask2 |= (1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK2,
- m-mask2);
- } else {
- m-mask1 |= (1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK1,
- m-mask1);
- }
-}
-
-static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7)
- return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 (irq - 8));
- else
- return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
-}
-
static void menelaus_irq_ack(struct irq_data *data)
{
struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
@@ -322,47 +285,15 @@ static struct irq_chip menelaus_irq_chip = {
.irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
};
-/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
- void (*handler)(struct menelaus_chip *))
-{
- int ret = 0;
-
- mutex_lock(m-lock);
- m-handlers[irq] = handler;
- ret = menelaus_enable_irq(m, irq);
- mutex_unlock(m-lock);
-
- return ret;
-}
-
-/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
-{
- int ret = 0;
-
- mutex_lock(m-lock);
- ret = menelaus_disable_irq(m, irq);
- m-handlers[irq] = NULL;
- mutex_unlock(m-lock);
-
- return ret;
-}
-
-/*
- * Gets scheduled when a card detect interrupt happens. Note that in some cases
- * this line is wired to card cover switch rather than the card detect switch
- * in each slot. In this case the cards are not seen by menelaus.
- * FIXME: Add handling for D1 too
- */
-static void menelaus_mmc_cd_work(struct menelaus_chip *m)
+static irqreturn_t menelaus_mmc_cd_irq(int irq, void *_m)
{
- int reg;
+ struct menelaus_chip *m = _m;
unsigned char card_mask = 0;
+ int reg;
reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg 0)
- return;
+ return IRQ_NONE;
if (!(reg 0x1))
card_mask |= MCT_PIN_ST_S1_CD_ST;
@@ -373,6 +304,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip *m)
if (m-mmc_callback)
m-mmc_callback(m-mmc_callback_data,
card_mask);
+
+ return IRQ_HANDLED;
}
/*
@@ -504,20 +437,25 @@ int menelaus_register_mmc_callback(void (*callback)(void
*data, u8 card_mask),
m-mmc_callback_data = data;
m-mmc_callback = callback;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
- menelaus_mmc_cd_work);
+
+ ret = request_threaded_irq(MENELAUS_MMC_S1CD_IRQ + m-irq_base,
+ NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+ mmc_s1cd, m);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
- menelaus_mmc_cd_work);
+ ret = request_threaded_irq(MENELAUS_MMC_S2CD_IRQ + m-irq_base,
+ NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+ mmc_s2cd, m);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
- menelaus_mmc_cd_work);
+
[PATCH v3 04/15] mfd: menelaus: Remove unnecessary loop
We can let irqs refire and give the scheduler a chance to choose when we
should be scheduled.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 43 +++
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 11d7d81..11dc4d3 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,30 +795,25 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
-
- while (1) {
- unsigned isr;
-
- isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-~menelaus-mask2) 8;
- isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-~menelaus-mask1;
- if (!isr)
- break;
-
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
- mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
- if (handler)
- handler(menelaus);
- menelaus_enable_irq(irq);
- mutex_unlock(menelaus-lock);
- }
+ unsigned isr;
+
+ isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
+~menelaus-mask2) 8;
+ isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
+~menelaus-mask1;
+
+ while (isr) {
+ int irq = fls(isr) - 1;
+ isr = ~(1 irq);
+
+ mutex_lock(menelaus-lock);
+ menelaus_disable_irq(irq);
+ menelaus_ack_irq(irq);
+ handler = menelaus-handlers[irq];
+ if (handler)
+ handler(menelaus);
+ menelaus_enable_irq(irq);
+ mutex_unlock(menelaus-lock);
}
return IRQ_HANDLED;
--
1.8.4.GIT
--
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 06/15] mfd: menelaus: Pass menelaus pointer as argument to enable/disable irq
We want to, eventually, get rid of the global the_menelaus pointer, so
let's start passing menelaus as argument to some function calls and
slowly phase out the_menelaus global pointer.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 48
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 9ccbb79..4c51e4b 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -199,35 +199,35 @@ static int menelaus_read_reg(int reg)
return val;
}
-static int menelaus_enable_irq(int irq)
+static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
{
if (irq 7) {
irq -= 8;
- the_menelaus-mask2 = ~(1 irq);
+ m-mask2 = ~(1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK2,
- the_menelaus-mask2);
+ m-mask2);
} else {
- the_menelaus-mask1 = ~(1 irq);
+ m-mask1 = ~(1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK1,
- the_menelaus-mask1);
+ m-mask1);
}
}
-static int menelaus_disable_irq(int irq)
+static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
{
if (irq 7) {
irq -= 8;
- the_menelaus-mask2 |= (1 irq);
+ m-mask2 |= (1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK2,
- the_menelaus-mask2);
+ m-mask2);
} else {
- the_menelaus-mask1 |= (1 irq);
+ m-mask1 |= (1 irq);
return menelaus_write_reg(MENELAUS_INT_MASK1,
- the_menelaus-mask1);
+ m-mask1);
}
}
-static int menelaus_ack_irq(int irq)
+static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
{
if (irq 7)
return menelaus_write_reg(MENELAUS_INT_ACK2, 1 (irq - 8));
@@ -243,7 +243,7 @@ static int menelaus_add_irq_work(int irq,
mutex_lock(the_menelaus-lock);
the_menelaus-handlers[irq] = handler;
- ret = menelaus_enable_irq(irq);
+ ret = menelaus_enable_irq(the_menelaus, irq);
mutex_unlock(the_menelaus-lock);
return ret;
@@ -255,7 +255,7 @@ static int menelaus_remove_irq_work(int irq)
int ret = 0;
mutex_lock(the_menelaus-lock);
- ret = menelaus_disable_irq(irq);
+ ret = menelaus_disable_irq(the_menelaus, irq);
the_menelaus-handlers[irq] = NULL;
mutex_unlock(the_menelaus-lock);
@@ -793,25 +793,25 @@ out:
static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
- struct menelaus_chip *menelaus = _menelaus;
- void (*handler)(struct menelaus_chip *menelaus);
+ struct menelaus_chip *m = _menelaus;
+ void (*handler)(struct menelaus_chip *m);
unsigned long isr;
unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-~menelaus-mask2) 8;
+~m-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-~menelaus-mask1;
+~m-mask1;
for_each_set_bit(i, isr, 16) {
- mutex_lock(menelaus-lock);
- menelaus_disable_irq(i);
- menelaus_ack_irq(i);
- handler = menelaus-handlers[i];
+ mutex_lock(m-lock);
+ menelaus_disable_irq(m, i);
+ menelaus_ack_irq(m, i);
+ handler = m-handlers[i];
if (handler)
- handler(menelaus);
- menelaus_enable_irq(i);
- mutex_unlock(menelaus-lock);
+ handler(m);
+ menelaus_enable_irq(m, i);
+ mutex_unlock(m-lock);
}
return IRQ_HANDLED;
--
1.8.4.GIT
--
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 01/15] mfd: menelaus: Drop __exit section annotation
We could build that driver as a dynamically-linked module.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index ad25bfa..975ff9e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1262,7 +1262,7 @@ fail:
return err;
}
-static int __exit menelaus_remove(struct i2c_client *client)
+static int menelaus_remove(struct i2c_client *client)
{
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
@@ -1283,7 +1283,7 @@ static struct i2c_driver menelaus_i2c_driver = {
.name = DRIVER_NAME,
},
.probe = menelaus_probe,
- .remove = __exit_p(menelaus_remove),
+ .remove = menelaus_remove,
.id_table = menelaus_id,
};
--
1.8.4.GIT
--
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 14/15] mfd: menelaus: IRQ is a requirement
This driver needs IRQ to work, if client-irq isn't set properly, we
won't work. Remove check around request_threaded_irq().
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index c0219b7..bffe978 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1271,14 +1271,12 @@ static int menelaus_probe(struct i2c_client *client,
/* Set output buffer strengths */
menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73);
- if (client-irq 0) {
- err = request_threaded_irq(client-irq, NULL, menelaus_irq,
- IRQF_ONESHOT, DRIVER_NAME, m);
- if (err) {
- dev_dbg(client-dev, can't get IRQ %d, err %d\n,
- client-irq, err);
- goto fail_free_descs;
- }
+ err = request_threaded_irq(client-irq, NULL, menelaus_irq,
+ IRQF_ONESHOT, DRIVER_NAME, m);
+ if (err) {
+ dev_dbg(client-dev, can't get IRQ %d, err %d\n,
+ client-irq, err);
+ goto fail_free_descs;
}
pr_info(Menelaus rev %d.%d\n, rev 4, rev 0x0f);
--
1.8.4.GIT
--
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 03/15] mfd: menelaus: Convert to threaded irq
We don't need that extra workqueue when we have generic threaded irq
handlers support. This patch just moves over to threaded irqs and
deletes the unnecessary workqueue.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 29 -
1 file changed, 4 insertions(+), 25 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8bd97ca..11d7d81 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -36,7 +36,6 @@
#include linux/interrupt.h
#include linux/sched.h
#include linux/mutex.h
-#include linux/workqueue.h
#include linux/delay.h
#include linux/rtc.h
#include linux/bcd.h
@@ -161,12 +160,9 @@
#define MCT_PIN_ST_S1_CD_ST(1 0)
#define MCT_PIN_ST_S2_CD_ST(1 1)
-static void menelaus_work(struct work_struct *_menelaus);
-
struct menelaus_chip {
struct mutexlock;
struct i2c_client *client;
- struct work_struct work;
#ifdef CONFIG_RTC_DRV_TWL92330
struct rtc_device *rtc;
u8 rtc_control;
@@ -795,11 +791,9 @@ out:
/*---*/
-/* Handles Menelaus interrupts. Does not run in interrupt context */
-static void menelaus_work(struct work_struct *_menelaus)
+static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
- struct menelaus_chip *menelaus =
- container_of(_menelaus, struct menelaus_chip, work);
+ struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
while (1) {
@@ -826,18 +820,6 @@ static void menelaus_work(struct work_struct *_menelaus)
mutex_unlock(menelaus-lock);
}
}
- enable_irq(menelaus-client-irq);
-}
-
-/*
- * We cannot use I2C in interrupt context, so we just schedule work.
- */
-static irqreturn_t menelaus_irq(int irq, void *_menelaus)
-{
- struct menelaus_chip *menelaus = _menelaus;
-
- disable_irq_nosync(irq);
- (void)schedule_work(menelaus-work);
return IRQ_HANDLED;
}
@@ -1225,8 +1207,8 @@ static int menelaus_probe(struct i2c_client *client,
menelaus_write_reg(MENELAUS_MCT_CTRL1, 0x73);
if (client-irq 0) {
- err = request_irq(client-irq, menelaus_irq, 0,
- DRIVER_NAME, menelaus);
+ err = request_threaded_irq(client-irq, NULL, menelaus_irq,
+ IRQF_ONESHOT, DRIVER_NAME, menelaus);
if (err) {
dev_dbg(client-dev, can't get IRQ %d, err %d\n,
client-irq, err);
@@ -1235,7 +1217,6 @@ static int menelaus_probe(struct i2c_client *client,
}
mutex_init(menelaus-lock);
- INIT_WORK(menelaus-work, menelaus_work);
pr_info(Menelaus rev %d.%d\n, rev 4, rev 0x0f);
@@ -1258,7 +1239,6 @@ static int menelaus_probe(struct i2c_client *client,
return 0;
fail:
free_irq(client-irq, menelaus);
- flush_work(menelaus-work);
return err;
}
@@ -1267,7 +1247,6 @@ static int menelaus_remove(struct i2c_client *client)
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
free_irq(client-irq, menelaus);
- flush_work(menelaus-work);
the_menelaus = NULL;
return 0;
}
--
1.8.4.GIT
--
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 02/15] mfd: menelaus: Switch over to module_i2c_driver
Just a macro to remove some boilerplate code, no functional changes.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 975ff9e..8bd97ca 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1287,29 +1287,8 @@ static struct i2c_driver menelaus_i2c_driver = {
.id_table = menelaus_id,
};
-static int __init menelaus_init(void)
-{
- int res;
-
- res = i2c_add_driver(menelaus_i2c_driver);
- if (res 0) {
- pr_err(DRIVER_NAME : driver registration failed\n);
- return res;
- }
-
- return 0;
-}
-
-static void __exit menelaus_exit(void)
-{
- i2c_del_driver(menelaus_i2c_driver);
-
- /* FIXME: Shutdown menelaus parts that can be shut down */
-}
+module_i2c_driver(menelaus_i2c_driver);
MODULE_AUTHOR(Texas Instruments, Inc. (and others));
MODULE_DESCRIPTION(I2C interface for Menelaus.);
MODULE_LICENSE(GPL);
-
-module_init(menelaus_init);
-module_exit(menelaus_exit);
--
1.8.4.GIT
--
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 11/15] mfd: menelaus: Start to use irqdomain
Introduce an irq_chip and irq_domain for menelaus driver. Following
patches will convert uses to traditional request_threaded_irq().
While at that, some better error handling had to be added, so we could
free irq descs we allocated.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 127 ++---
1 file changed, 120 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index aa3c579..e4f33b7 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -34,6 +34,7 @@
#include linux/module.h
#include linux/i2c.h
#include linux/interrupt.h
+#include linux/irqdomain.h
#include linux/sched.h
#include linux/mutex.h
#include linux/delay.h
@@ -47,6 +48,7 @@
#include asm/gpio.h
#define DRIVER_NAMEmenelaus
+#define MENELAUS_NR_IRQS 16
#define MENELAUS_I2C_ADDRESS 0x72
@@ -168,11 +170,19 @@ struct menelaus_chip {
u8 rtc_control;
unsigneduie:1;
#endif
+ int irq_base;
unsignedvcore_hw_mode:1;
u8 mask1, mask2;
+ u8 ack1, ack2;
+
void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
+
+ unsignedmask1_pending:1;
+ unsignedmask2_pending:1;
+ unsignedack1_pending:1;
+ unsignedack2_pending:1;
};
static struct menelaus_chip *the_menelaus;
@@ -235,6 +245,83 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int
irq)
return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
}
+static void menelaus_irq_ack(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-ack2 |= BIT(irq);
+ m-ack2_pending = true;
+ } else {
+ m-ack1 |= BIT(irq);
+ m-ack1_pending = true;
+ }
+}
+
+static void menelaus_irq_mask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-mask2 |= BIT(irq);
+ m-mask2_pending = true;
+ } else {
+ m-mask1 |= BIT(irq);
+ m-mask1_pending = true;
+ }
+}
+
+static void menelaus_irq_unmask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-mask2 = ~BIT(irq);
+ m-mask2_pending = true;
+ } else {
+ m-mask1 = ~BIT(irq);
+ m-mask1_pending = true;
+ }
+}
+
+static void menelaus_irq_bus_lock(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+ mutex_lock(m-lock);
+}
+
+static void menelaus_irq_bus_sync_unlock(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+ if (m-ack1_pending)
+ menelaus_write_reg(m, MENELAUS_INT_ACK1, m-ack1);
+
+ if (m-ack2_pending)
+ menelaus_write_reg(m, MENELAUS_INT_ACK2, m-ack2);
+
+ if (m-mask1_pending)
+ menelaus_write_reg(m, MENELAUS_INT_MASK1, m-mask1);
+
+ if (m-mask2_pending)
+ menelaus_write_reg(m, MENELAUS_INT_MASK2, m-mask2);
+
+ mutex_unlock(m-lock);
+}
+
+static struct irq_chip menelaus_irq_chip = {
+ .name = menelaus,
+ .irq_ack= menelaus_irq_ack,
+ .irq_mask = menelaus_irq_mask,
+ .irq_unmask = menelaus_irq_unmask,
+ .irq_bus_lock = menelaus_irq_bus_lock,
+ .irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
+};
+
/* Adds a handler for an interrupt. Does not run in interrupt context */
static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
@@ -1186,8 +1273,11 @@ static int menelaus_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct menelaus_chip*m;
+ struct device_node *node = client-dev.of_node;
int rev = 0, val;
int err = 0;
+ int irq_base;
+ int i;
struct menelaus_platform_data *menelaus_pdata =
dev_get_platdata(client-dev);
@@ -1205,12 +1295,32 @@ static int menelaus_probe(struct i2c_client *client,
the_menelaus = m;
m-client = client;
+ mutex_init(m-lock);
+
+ irq_base =
[PATCH v3 13/15] mfd: menelaus: Remove unnecessary definition
menelaus_i2c_driver isn't referenced on probe, just remove that
unnecessary line. No functional changes.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 74eae19..c0219b7 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1206,8 +1206,6 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
/*---*/
-static struct i2c_driver menelaus_i2c_driver;
-
static int menelaus_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
--
1.8.4.GIT
--
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 15/26] ARM: omap4-panda.dts: add display information
Hi Tomi,
On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-09 17:09, Javier Martinez Canillas wrote:
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio1 0 0; /* 0, power-down */
+
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = gpio1 0 GPIO_ACTIVE_HIGH; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is power-down. I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
as it were active-low. The flag is ignored.
How weird, it does work on the IGEPv2 but you are right I just looked
at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
that it indeed just does:
r = devm_gpio_request_one(pdev-dev, ddata-pd_gpio,
GPIOF_OUT_INIT_LOW, tfp410 PD);
So I don't know how it is working... I'm on the road and won't have
access to my IGEPv2 to dig further on this. Maybe Enric can shed more
light on this.
Tomi
Thanks a lot and best regards,
Javier
--
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 5/8] gpio: twl4030: Fix regression for twl gpio output
* Linus Walleij linus.wall...@linaro.org [131209 05:10]: On Tue, Dec 3, 2013 at 2:30 PM, Roger Quadros rog...@ti.com wrote: (...) This patch causes a regression with LED outputs (GPO) on twl4030 on 3.13-rc2. As one of the LED GPO is used for USB host on beagleboard, it will cause failure of USB host probe. (...) Below is a proposed fix for this. Roger, Tony: what happened with this? Have you hashed this out? I ACK Roger's fixup too if that needs to be merged into the OMAP tree. There's an updated version from Roger posted that I acked: [PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output http://lkml.org/lkml/2013/12/5/65 I also commented on the dependencies there, but basically you can pick it up unless you want me to. Should be cc stable as well. 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: OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5)
* Paul Walmsley p...@pwsan.com [131209 01:55]: On Mon, 25 Nov 2013, Paul Walmsley wrote: On Mon, 25 Nov 2013, Paul Walmsley wrote: Boot to userspace: FAIL ( 1/11): 37xxevm So looks like this is due to the switchover to DT-based booting for 37xx EVM. Will plug that in here and re-test. Here's the updated test report. Looks like dynamic idle PM tests are failing on the 37xxevm now. Off-idle and wake-up events work but need these two pending patches: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 2. [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree http://www.spinics.net/lists/devicetree/msg13374.html Without the first one we get some nasty looking harmless warnings, so I've been holding off to merging #2 until #1 is fixed. 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 v2 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
* Javier Martinez Canillas jav...@dowhile0.org [131209 03:51]: Hi Kishon, On Mon, Dec 9, 2013 at 7:07 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Saturday 07 December 2013 02:38 AM, Felipe Balbi wrote: Hi, On Fri, Dec 06, 2013 at 01:14:38PM +0100, Javier Martinez Canillas wrote: On Fri, Dec 6, 2013 at 1:06 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while creating MUSB core device. So in usb_bind_phy (binds the controller with the PHY), the device name of the controller had *.auto* in it. Since with using PLATFORM_DEVID_AUTO, there is no way to know the exact device name in advance, the data given in usb_bind_phy became obsolete and usb_get_phy was failing. So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding change is done in board file here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- 12 files changed, 12 insertions(+), 12 deletions(-) You can drop this patch since boards files are being removed for v3.14 if we can drop this patch, the whole series is invalid, since we'll be using DT phandles to find PHYs going forward, no ? yeah. But in one of the other threads, Tony seemed ok to take a patch that fixes the same issue in mach-omap2/twl-common.c. So it's better to confirm with Tony. Yes, I just read the other thread ([PATCH] omap: twl-common: Fix musb-hdrc device name) and I see that these patches are fixing a v3.13 regression and are meant for the -rc cycle and not for v3.14. Sorry guys, I'm a bit lost with these USB regression fixes. Which regression fix do we need for v3.13-rc series? If there's an option, I'd rather not touch all the board-*.c files as those are about to get dropped for v3.14. 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: [PATCHv2 09/10] arm: dts: dra7: Add qspi device.
* Sourav Poddar sourav.pod...@ti.com [131206 06:29]:
These add device tree entry for qspi controller driver on dra7.
FYI these .dts changes need to be queued separately by Benoit and
should be posted as a seprate series in general to avoid confusion.
Regards,
Tony
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2:
use MUX_MODE1 instead of numeric value
arch/arm/boot/dts/dra7-evm.dts | 32
arch/arm/boot/dts/dra7.dtsi| 13 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..4a57fdf 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,21 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ qspi1_pins: pinmux_qspi1_pins {
+ pinctrl-single,pins =
+ 0x4c (PIN_INPUT | MUX_MODE1) /* gpmc_a3.qspi1_cs2 */
+ 0x50 (PIN_INPUT | MUX_MODE1) /* gpmc_a4.qspi1_cs3 */
+ 0x74 (PIN_INPUT | MUX_MODE1) /* gpmc_a13.qspi1_rtclk */
+ 0x78 (PIN_INPUT | MUX_MODE1) /* gpmc_a14.qspi1_d3 */
+ 0x7c (PIN_INPUT | MUX_MODE1) /* gpmc_a15.qspi1_d2 */
+ 0x80 (PIN_INPUT | MUX_MODE1) /* gpmc_a16.qspi1_d1 */
+ 0x84 (PIN_INPUT | MUX_MODE1) /* gpmc_a17.qspi1_d0 */
+ 0x88 (PIN_INPUT | MUX_MODE1) /* qpmc_a18.qspi1_sclk */
+ 0xb8 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs2.qspi1_cs0 */
+ 0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs3.qspi1_cs1 */
+ ;
+ };
};
i2c1 {
@@ -273,3 +288,20 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+qspi {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = qspi1_pins;
+
+ spi-max-frequency = 4800;
+ m25p80@0 {
+ compatible = s25fl256s1;
+ spi-max-frequency = 4800;
+ reg = 0;
+ spi-tx-bus-width = 1;
+ spi-rx-bus-width = 4;
+ spi-cpol;
+ spi-cpha;
+ };
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 67275c8..b06d899 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -582,6 +582,19 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ qspi: qspi@4b30 {
+ compatible = ti,dra7xxx-qspi;
+ reg = 0x4b30 0x100, 0x4a002558 0x4,
+ 0x5c00 0x3ff;
+ reg-names = qspi_base, qspi_ctrlmod, qspi_mmap;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = qspi;
+ num-cs = 4;
+ interrupts = 0 124 0x4;
+ status = disabled;
+ };
};
clocks {
--
1.7.1
--
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
--
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] Documentation: dt: Document TSC2005 DT binding
* Sebastian Reichel s...@debian.org [131205 15:11]:
Add devicetree binding documentation for TSC2005 touchscreen.
Signed-off-by: Sebastian Reichel s...@debian.org
---
.../bindings/input/touchscreen/tsc2005.txt | 49
++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 000..4e7df0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,49 @@
+* TSC2005 Touchscreen
+
+Required properties:
+ - compatible : ti,tsc2005
+ - reg : SPI device address
+ - spi-max-frequency : Maximal SPI speed
+ - interrupts : IRQ specifier
+ - reset-gpio : GPIO specifier
+
+Optional properties:
+ - ti,fuzz-x : integer, X noise value of the touchscreen
+ (defaults to 4)
+ - ti,fuzz-y : integer, Y noise value of the touchscreen
+ (defaults to 8)
+ - ti,fuzz-pressure: integer, pressure noise value of the touchscreen
+ (defaults to 2)
+ - ti,max-x: integer, maximum reported x value
+ (defaults to 4096)
+ - ti,max-y: integer, maximum reported y value
+ (defaults to 4096)
+ - ti,max-pressure : integer, maximum reported pressure
+ (defaults to 4096)
+ - ti,x-plate-resistance : integer, resistance of the touchscreen's X
plates
+ in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond
after
+ the configured time (in milli seconds), the
driver
+ will reset it. This is disabled by default.
Instead of adding these optional ti,* properties you can set them in the
driver directly in the of_match table based on the compatible flag. Then
you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of
the LCD panel. Most likely these depend on the LCD panel selected.
Regards,
Tony
+Example:
+
+mcspi1 {
+ tsc2005@0 {
+ compatible = ti,tsc2005;
+ spi-max-frequency = 600;
+ reg = 0;
+ reset-gpio = gpio4 8 GPIO_ACTIVE_HIGH; /* 104 */
+ interrupt-parent = gpio4;
+ interrupts = 4 IRQ_TYPE_NONE; /* gpio line 100 */
+
+ ti,fuzz-x = 4;
+ ti,fuzz-y = 7;
+ ti,fuzz-pressure = 2;
+ ti,max-x = 4096;
+ ti,max-y = 4096;
+ ti,max-pressure = 2048;
+ ti,x-plate-resistance = 280;
+ ti,esd-recovery-timeout-ms = 8000;
+ };
+}
--
1.8.4.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
--
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: twl-common: Fix musb-hdrc device name.
* Belisko Marek marek.beli...@gmail.com [131208 23:36]: Hi Tony, On Thu, Dec 5, 2013 at 7:43 PM, Tony Lindgren t...@atomide.com wrote: * Belisko Marek marek.beli...@gmail.com [131203 01:21]: On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: Without this change when booting omap3 device (gta04) with board file leads to follwing errors: [1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy [1.209075] HS USB OTG: no transceiver configured [1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 and usb isn't working. This is probably regression caused by commit: 6c27f939 I think a better fix would be to have this merged.. https://lkml.org/lkml/2013/7/26/91 Yes I see but how this could help with current situation? Ho you then specify device number? I was too fast with reply sorry. I can see whole series and it is of course correct solution. But as I said can we except to be merged to 3.13. If not Tony can you pick my patch. If it's a regression, then let's get it merged for the -rc cycle. Yes it is regression and without that usb on most omap3 based boards without DT will not work. So please try to follow up on getting the proper fix merged, meanwhile I'll mark this thread as read. If you need this one merged for some reason, then please report to get it back to my radar. I'm still clueless which USB regression fix to apply for the -rc cycle though.. Hoping to see a single patch which clearly states the issue and has acks. 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 1/3] ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module
Salut Paul,
On 08/12/2013 17:26, Paul Walmsley wrote:
Hi Benoît,
On Tue, 3 Dec 2013, Roger Quadros wrote:
Without this, the USB devices are sometimes not detected on OMAP4 Panda
with u-boot v2013.10.
Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.
RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Will you pick this up for the -rc series, or do you want me or Tony to?
Roger writes that this one's pretty important.
I guess, it is better for you to take it. I don't have anything queued
for -rc.
Acked-by: Benoit Cousson bcous...@baylibre.com
Thanks,
Benoit
- Paul
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++--
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 +++--
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1e5b12c..3318cae9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2937,7 +2937,7 @@ static struct omap_hwmod_class_sysconfig
omap44xx_usb_host_hs_sysc = {
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
- SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SOFTRESET | SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -3001,15 +3001,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 9e08d69..e297d62 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1544,7 +1544,8 @@ static struct omap_hwmod_class_sysconfig
omap54xx_usb_host_hs_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
.sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
@@ -1598,15 +1599,7 @@ static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
* hence HWMOD_SWSUP_MSTANDBY
*/
- /*
-* During system boot; If the hwmod framework resets the module
-* the module will have smart idle settings; which can lead to deadlock
-* (above Errata Id:i660); so, dont reset the module during boot;
-* Use HWMOD_INIT_NO_RESET.
-*/
-
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
- HWMOD_INIT_NO_RESET,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = l3init_60m_fclk,
.prcm = {
.omap4 = {
--
1.8.3.2
- Paul
--
Benoît Cousson
BayLibre
Embedded Linux Technology Lab
www.baylibre.com
--
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 13/26] ARM: omap3.dtsi: add omapdss information
* Tomi Valkeinen tomi.valkei...@ti.com [131209 04:46]: On 2013-12-05 19:05, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131204 04:31]: Description missing.. But other than that can you please check that the latest patch I posted in thread [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device works with this? The test to do is to remove the related reg, interrupt and dma entries from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized from DT properly. I made a quick test with panda, by applying your patch and reverting b38911f3472be89551bfca740adf0009562b9873. That only effectively tests the DISPC IRQ, but that worked fine. OK I've finally pushed a real branch for the mach-omap2 board-*.c file removal patches at omap-for-v3.14/omap3-board-removal so you can use that as a base for testing. I did not apply the dpi panel pdata-quirks.c patch as we discussed earlier. I don't know if it makes sense to have them as children of dss_core, they really all seem to be completely independent devices? The DSS subdevices depend on the dss_core. dss_core has to be powered up for any of the subdevices to work. This is done automatically by the runtime PM when the subdevices are children of the dss_core. OK thanks. Care to also check that it plays along nicely with the comments starting at line 3222 in omap_hwmod_3xxx_data.c? We should set up things so we can eventually remove those kind of hwmod workarounds. BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods property and do the lookup based on the compatible property instead ;) So from that point of view we need to get the device mapping right in the .dtsi files, and don't want to start mixing up separate devices into single .dtsi entry. Hmm, was that just a general comment, or something that affects the DSS DT data I have in my patch? As far as I understand, the DSS nodes reflect the current hwmods correctly. Yes that's what we want if there is a dependency to the dss_core at the hardware level and the children cannot be used independently. However, if the children can be enabled and clocked independently, then they should not be children of the dss_core. With the exception that DPI and SDI do not have a matching hwmod, as they are really part of dss_core/dispc. They are separate nodes as they are video outputs the same way as the other subnodes. I could perhaps remove the DPI and SDI nodes, and have them as direct video ports from DISPC, but... That's easier said than done. If you need a dev entry created for those where the phandle of that dev is used to select the output for a board, then it makes sense to have them. I guess you could also set them as a pinctrl mux controller and then the board specific .dts file could request those outputs. But there may be more than just mux involved like regulators. 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] Documentation: dt: Document TSC2005 DT binding
On Mon, Dec 09, 2013 at 09:46:38AM -0800, Tony Lindgren wrote: +Optional properties: + - ti,fuzz-x : integer, X noise value of the touchscreen + (defaults to 4) + - ti,fuzz-y : integer, Y noise value of the touchscreen + (defaults to 8) + - ti,fuzz-pressure : integer, pressure noise value of the touchscreen + (defaults to 2) + - ti,max-x : integer, maximum reported x value + (defaults to 4096) + - ti,max-y : integer, maximum reported y value + (defaults to 4096) + - ti,max-pressure : integer, maximum reported pressure + (defaults to 4096) + - ti,x-plate-resistance : integer, resistance of the touchscreen's X plates + in ohm (defaults to 280) + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after + the configured time (in milli seconds), the driver + will reset it. This is disabled by default. Instead of adding these optional ti,* properties you can set them in the driver directly in the of_match table based on the compatible flag. Then you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of the LCD panel. Most likely these depend on the LCD panel selected. I could certainly do this, but it would move the board specific data from the boardcode into the driver. That looks contra-productive to me. Is there a good reason to do it this way? -- Sebastian signature.asc Description: Digital signature
[GIT PULL] ARM: OMAP2+: hwmod code/data: fixes for v3.13-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.13-rc/hwmod-fixes-a for you to fetch changes up to 0e7dc862cf687234ed1b01a6b2461b782ea0bca0: ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present (2013-12-09 11:51:30 -0700) - ARM: OMAP2+: hwmod code/data: fixes for v3.13-rc Fix a few hwmod code problems involving recovery with bad data and bad IP block OCP reset handling. Also, fix the hwmod data to enable IP block OCP reset for the OMAP USBHOST devices on OMAP3+. Basic build, boot, and PM tests are available here: http://www.pwsan.com/omap/testlogs/prcm_fixes_a_v3.13-rc/20131209030611/ - Nishanth Menon (1): ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present Roger Quadros (3): ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module ARM: OMAP2+: hwmod: Fix SOFTRESET logic ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module arch/arm/mach-omap2/omap_hwmod.c | 45 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 ++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 ++--- 4 files changed, 52 insertions(+), 31 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSphSWAAoJEMePsQ0LvSpLBGwP/19ygCpEptuQk3AKY411jgXl rGEkdGlYcoHSd03ci2LjKds7iJgDnWdpCbrtfcRBmqSChlTk1AKqs8bnkQqYpY9P j5g3aacwROsutc74xCDJFHY0mAIQ1wfIoj5oUmM3mgX4ftKpNyYZ0gRxfPX/29eO YwOjzXEyHeRJ20UwL41Tp24Q1O6hziCDc1N0iMa+Yzbaf1Lwbq8la7FxOdmj+6la ex06qt0VELv9B3gQATR8lvDoFIlJ+3AVDnR5z1ODRvZqE1XKMZ7koF/La6fBqfqd pk7Nq7x3sN3TtDQb1dkvIrCOVwqYZnjkLXZ5UNam6tTnmDkB50ttoaJIoO0t+BA5 ALRkC9ni1StKKInTCJr1ncSmzaY1xCU1ePOrcxVDOvsxvmcUBtX50d9kRAssfkze eanyJoCBAKIgSR82vpaS4qwGsiPRU4NPPIcKvtsWzd9Oot84QvDOGvVv5730l9iU csJWay8rba9THbBNoghg2y5P4MBtsXFxCif1kXGyp9JZCek4wQZJAiHzXxqu/DIO QcK2uHwVNWS/vlyvoUmu3BB0p08sy5xKHm/eqwAS3bUag42vK4YI1Q6bfulXmt5W dslDMwVf/BbbbKO8Tee3vIWVc6NNVV5NHKTRvRtL85vt2+X63Ld1oZvOBq5A/hoF x4Gdw6dkexIhE+5YsuHN =hGE8 -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: OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5)
* Tony Lindgren t...@atomide.com [131209 09:17]: * Paul Walmsley p...@pwsan.com [131209 01:55]: On Mon, 25 Nov 2013, Paul Walmsley wrote: On Mon, 25 Nov 2013, Paul Walmsley wrote: Boot to userspace: FAIL ( 1/11): 37xxevm So looks like this is due to the switchover to DT-based booting for 37xx EVM. Will plug that in here and re-test. Here's the updated test report. Looks like dynamic idle PM tests are failing on the 37xxevm now. Off-idle and wake-up events work but need these two pending patches: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 Oops, this is the wrong patch, it should be: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 2. [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree http://www.spinics.net/lists/devicetree/msg13374.html Without the first one we get some nasty looking harmless warnings, so I've been holding off to merging #2 until #1 is fixed. 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: OMAP baseline test results for v3.13-rc1 (toolchain Debian 4.7.2-5)
* Tony Lindgren t...@atomide.com [131209 11:16]: * Tony Lindgren t...@atomide.com [131209 09:17]: * Paul Walmsley p...@pwsan.com [131209 01:55]: On Mon, 25 Nov 2013, Paul Walmsley wrote: On Mon, 25 Nov 2013, Paul Walmsley wrote: Boot to userspace: FAIL ( 1/11): 37xxevm So looks like this is due to the switchover to DT-based booting for 37xx EVM. Will plug that in here and re-test. Here's the updated test report. Looks like dynamic idle PM tests are failing on the 37xxevm now. Off-idle and wake-up events work but need these two pending patches: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 Oops, this is the wrong patch, it should be: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 Never mind, I need to take a break. 2. [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree http://www.spinics.net/lists/devicetree/msg13374.html Without the first one we get some nasty looking harmless warnings, so I've been holding off to merging #2 until #1 is fixed. Regards, Tony ___ Kernel-build-reports mailing list kernel-build-repo...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/kernel-build-reports -- 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.13-rc1 (toolchain Debian 4.7.2-5)
Hello. On 12/09/2013 10:14 PM, Tony Lindgren wrote: Boot to userspace: FAIL ( 1/11): 37xxevm So looks like this is due to the switchover to DT-based booting for 37xx EVM. Will plug that in here and re-test. Here's the updated test report. Looks like dynamic idle PM tests are failing on the 37xxevm now. Off-idle and wake-up events work but need these two pending patches: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 Oops, this is the wrong patch, it should be: 1. [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 Isn't it the same patch and link? :-) WBR, Sergei -- 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] ARM: dts: Add basic devices for AM3517-craneboard
Craneboard is a hardware development platform based on the Sitara
AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
details. Add basic devices for craneboard as replacement for the board
file scheduled for removal as part of device tree conversion
[1] http://craneboard.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
branch: omap-for-v3.14/omap3-board-removal 736e812 ARM: OMAP2+: Remove unused
platform init code and headers
Bootlog: http://pastebin.mozilla.org/3744412
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/am3517-craneboard.dts | 174 +++
2 files changed, 175 insertions(+)
create mode 100644 arch/arm/boot/dts/am3517-craneboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fc37bca..ad155fc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -205,6 +205,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-boneblack.dtb \
am335x-nano.dtb \
am335x-base0033.dtb \
+ am3517-craneboard.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
am43x-epos-evm.dtb \
diff --git a/arch/arm/boot/dts/am3517-craneboard.dts
b/arch/arm/boot/dts/am3517-craneboard.dts
new file mode 100644
index 000..2d40b3f
--- /dev/null
+++ b/arch/arm/boot/dts/am3517-craneboard.dts
@@ -0,0 +1,174 @@
+/*
+ * See craneboard.org for more details
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include am3517.dtsi
+
+/ {
+ model = TI AM3517 CraneBoard (TMDSEVM3517);
+ compatible = ti,am3517-craneboard, ti,am3517, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vbat;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-boot-on;
+ };
+};
+
+davinci_emac {
+ status = okay;
+};
+
+davinci_mdio {
+ status = okay;
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ tps: tps@2d {
+ reg = 0x2d;
+ };
+};
+
+i2c2 {
+ clock-frequency = 40;
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+i2c3 {
+ clock-frequency = 40;
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+mmc1 {
+ vmmc-supply = vdd2_reg;
+ bus-width = 8;
+};
+
+mmc2 {
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+mmc3 {
+ /* goes to expansion connector */
+ status = disabled;
+};
+
+#include tps65910.dtsi
+
+omap3_pmx_core {
+ tps_pins: pinmux_tps_pins {
+ pinctrl-single,pins =
+ 0x1b0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
sys_nirq.sys_nirq */
+ ;
+ };
+};
+
+tps {
+ pinctrl-names = default;
+ pinctrl-0 = tps_pins;
+
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ ti,en-ck32k-xtal;
+
+ vcc1-supply = vbat;
+ vcc2-supply = vbat;
+ vcc3-supply = vbat;
+ vcc4-supply = vbat;
+ vcc5-supply = vbat;
+ vcc6-supply = vbat;
+ vcc7-supply = vbat;
+ vccio-supply = vbat;
+
+ regulators {
+ vrtc_reg: regulator@0 {
+ regulator-always-on;
+ };
+
+ vio_reg: regulator@1 {
+ regulator-always-on;
+ };
+
+ /*
+* Unused:
+* VDIG1=2.7V,300mA max
+* VDIG2=1.8V,300mA max
+*/
+
+ vpll_reg: regulator@7 {
+ /* VDDS_DPLL_1V8 */
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ vaux1_reg: regulator@9 {
+ /* VDDS_SRAM_1V8 */
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ vaux2_reg: regulator@10 {
+ /* VDDA1P8V_USBPHY */
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ /* VAUX33 unused */
+
+ vdac_reg: regulator@8 {
+ /* VDDA_DAC_1V8 */
+
Re: [GIT PULL] two regression fixes and two more omap dt fixes against v3.13-rc2
Tony Lindgren t...@atomide.com writes: The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e: Linux 3.13-rc3 (2013-12-06 09:34:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/yet-more-dt-regressions-take2 for you to fetch changes up to f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) A rather big fix for a regression where we have dropped omap4 hwmod data earlier but are not initializing it from device tree. In addition to this fix we eventually also be fix the issues in the .dts files and drivers, but that's too intrusive for the -rc cycle and must be done later on. Also a fix for a regression where we now are wrongly trying to initialize devices on secure omaps like n900 and n9* when booted using device tree. We need to set aes, sham and timer12 to disabled mode for secure devices as they are claimed by the firmware running in the secure mode. And two more legacy booting vs device tree based booting fixes for am3517 that I did not notice earlier until Nishant Menon reported these to me few days ago. With these we're good to go having v3.13 working both for legacy booting and device tree based booting, and we can then go ahed and drop the legacy booting for mach-omap2 for v3.14. Pulled into fixes, Thanks, Kevin -- 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] Documentation: dt: Document TSC2005 DT binding
* Sebastian Reichel s...@debian.org [131209 10:25]: On Mon, Dec 09, 2013 at 09:46:38AM -0800, Tony Lindgren wrote: +Optional properties: + - ti,fuzz-x : integer, X noise value of the touchscreen + (defaults to 4) + - ti,fuzz-y : integer, Y noise value of the touchscreen + (defaults to 8) + - ti,fuzz-pressure: integer, pressure noise value of the touchscreen + (defaults to 2) + - ti,max-x: integer, maximum reported x value + (defaults to 4096) + - ti,max-y: integer, maximum reported y value + (defaults to 4096) + - ti,max-pressure : integer, maximum reported pressure + (defaults to 4096) + - ti,x-plate-resistance : integer, resistance of the touchscreen's X plates + in ohm (defaults to 280) + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after + the configured time (in milli seconds), the driver + will reset it. This is disabled by default. Instead of adding these optional ti,* properties you can set them in the driver directly in the of_match table based on the compatible flag. Then you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of the LCD panel. Most likely these depend on the LCD panel selected. I could certainly do this, but it would move the board specific data from the boardcode into the driver. That looks contra-productive to me. Is there a good reason to do it this way? You can leave out the custom properties that way for something that probably should be grouped by the touchpanel type connected as the values are the same. So for example just a few compatible flags like ti,tsc2005-panel-abc and ti,tsc2005-panel-xyz we could potentially cover all the configurations we're aware of without any need for custom properties. And this is way easier to support in the long run assuming we don't end up with tons of compatible flags. Of course if we end up with a new compatible flag for each configuration, then it makes sense to set up the custom properties, but I doubt that's the case here. 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: [GIT PULL] ARM: OMAP2+: hwmod code/data: fixes for v3.13-rc
Arnd, Kevin, Olof, Care to pull this one from Paul into the fixes too? Regards, Tony * Paul Walmsley p...@pwsan.com [131209 11:08]: Hi Tony, The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.13-rc/hwmod-fixes-a for you to fetch changes up to 0e7dc862cf687234ed1b01a6b2461b782ea0bca0: ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present (2013-12-09 11:51:30 -0700) ARM: OMAP2+: hwmod code/data: fixes for v3.13-rc Fix a few hwmod code problems involving recovery with bad data and bad IP block OCP reset handling. Also, fix the hwmod data to enable IP block OCP reset for the OMAP USBHOST devices on OMAP3+. Basic build, boot, and PM tests are available here: http://www.pwsan.com/omap/testlogs/prcm_fixes_a_v3.13-rc/20131209030611/ Nishanth Menon (1): ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present Roger Quadros (3): ARM: OMAP4+: hwmod data: Don't prevent RESET of USB Host module ARM: OMAP2+: hwmod: Fix SOFTRESET logic ARM: OMAP3: hwmod data: Don't prevent RESET of USB Host module arch/arm/mach-omap2/omap_hwmod.c | 45 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 ++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 12 ++-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 13 ++--- 4 files changed, 52 insertions(+), 31 deletions(-) -- 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 1/1] drivers: net : cpsw: Use netdev_name while requesting irq
From: Mugunthan V N mugunthan...@ti.com Date: Mon, 9 Dec 2013 14:59:05 +0530 commit 50a5fb068 This commit doesn't appear in any tree. And any change which makes a real struct device return NULL for dev_name() is broken. I'm not applying this patch, you have completely failed to provide any information necessary to support and justify your change. -- 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] thermal: ti-soc-thermal: clk_round_rate() can return a zero upon error
Treat both negative and zero return values from clk_round_rate() as
errors. This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather than a
signed type, since some clock sources can generate rates higher than
(2^31)-1 Hz.
Eventually, when calling clk_round_rate(), only a return value of zero
will be considered a error. All other values will be considered valid
rates. The comparison against values less than 0 is kept to preserve
the correct behavior in the meantime.
This patch also gets rid of a comparison between unsigned and signed
values; a side-benefit.
Signed-off-by: Paul Walmsley pwalms...@nvidia.com
Cc: Eduardo Valentin eduardo.valen...@ti.com
Cc: Zhang Rui rui.zh...@intel.com
---
Applies on v3.13-rc3. See also:
http://marc.info/?l=linux-arm-kernelm=138542591313620w=2
drivers/thermal/ti-soc-thermal/ti-bandgap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 74c0e3474d6e..8fe46dbc0c6f 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1248,7 +1248,7 @@ int ti_bandgap_probe(struct platform_device *pdev)
clk_rate = clk_round_rate(bgp-div_clk,
bgp-conf-sensors[0].ts_data-max_freq);
if (clk_rate bgp-conf-sensors[0].ts_data-min_freq ||
- clk_rate == 0x) {
+ clk_rate = 0) {
ret = -ENODEV;
dev_err(pdev-dev, wrong clock rate (%d)\n, clk_rate);
goto put_clks;
--
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] cpufreq: omap: clk_round_rate() can return a zero upon error
Treat both negative and zero return values from clk_round_rate() as
errors. This is needed since subsequent patches will convert
clk_round_rate()'s return value to be an unsigned type, rather than a
signed type, since some clock sources can generate rates higher than
(2^31)-1 Hz.
Eventually, when calling clk_round_rate(), only a return value of
zero will be considered a error. All other values will be
considered valid rates. The comparison against values less than
0 is kept to preserve the correct behavior in the meantime.
This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended
to be used only on combination pointer/error code return values; a
side-benefit.
Signed-off-by: Paul Walmsley pwalms...@nvidia.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Viresh Kumar viresh.ku...@linaro.org
---
Applies on v3.13-rc3. See also:
http://marc.info/?l=linux-arm-kernelm=138542591313620w=2
drivers/cpufreq/omap-cpufreq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index a0acd0bfba40..0f41eb2609f3 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -63,7 +63,7 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int index)
freq = new_freq * 1000;
ret = clk_round_rate(mpu_clk, freq);
- if (IS_ERR_VALUE(ret)) {
+ if (ret = 0) {
dev_warn(mpu_dev,
CPUfreq: Cannot find matching frequency for %lu\n,
freq);
--
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
[GIT PULL] make mach-omap2 boot with device tree only for v3.14
The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71: ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069: ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) We can now finally make mach-omap2 to boot with device tree only and get rid of over 20k lines of platform init code that way. Most basic devices already work using device tree based initialization and the remaining devices can be initialized using platform data with pdata-quirks.c. So for most missing boards it's just a question of adding a .dts file that should be fairly similar to one of the existing .dts files as we've tried to cover all basic omap3 board types. For people getting started updating their board files to for device tree, there are some basic instructions in commit 8dc8b3ddf5d7 (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting). Please also note that there are also some related fixes making their way into the mainline kernel that are needed for some use cases: PM off-idle for omap3 and wake-up events need the following two patches: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts http://lkml.org/lkml/2013/11/22/520 [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree http://www.spinics.net/lists/devicetree/msg13374.html EMAC Ethernet on am3517 boards needs: [PATCH] net: davinci_emac: Fix platform data handling and make usable for am3517 http://patchwork.ozlabs.org/patch/296351/ Ethernet for boards using smc91x needs: [PATCH v2] net: smc91x: Fix device tree based configuration so it's usable http://www.spinics.net/lists/netdev/msg258913.html Aaro Koskinen (1): ARM: OMAP2+: dts: add n8x0 onenand Javier Martinez Canillas (3): ARM: OMAP2+: Remove legacy smsc911x and smc91x GPMC support ARM: OMAP2+: Remove unnecesary include in GPMC driver ARM: OMAP2+: Remove legacy board-flash.c Tony Lindgren (34): mfd: twl-core: Fix passing of platform data in the device tree case Merge branch 'dt-regressions' into omap-for-v3.13/fixes-take4 ARM: dts: Add basic device tree support for omap2430 sdp ARM: dts: Add basic Nokia N8X0 support ARM: dts: Add basic support for omap3 LDP zoom1 labrador Merge branch 'omap-for-v3.13/fixes-take4' into omap-for-v3.14/board-removal Merge branch 'omap-for-v3.14/dt' into omap-for-v3.14/board-removal ARM: OMAP2+: Add support for board specific auxdata quirks ARM: OMAP2+: Add device tree compatible revision checks for n8x0 ARM: OMAP2+: Make n8x0 behave better with device tree based booting ARM: OMAP2+: Add quirks support for n8x0 ARM: OMAP2+: Remove legacy booting support for n8x0 ARM: OMAP2+: Remove board file for H4 ARM: OMAP2+: Remove legacy board file for 2430sdp ARM: OMAP2+: Remove legacy mux code for omap2 ARM: OMAP2+: Remove legacy hwmod entries for omap2 Merge branch 'omap-for-v3.14/board-removal' into omap-for-v3.14/omap3-board-removal ARM: OMAP2+: Add support for legacy auxdata for twl ARM: OMAP2+: Use pdata quirks for emac on am3517 ARM: dts: Add basic devices on am3517-evm ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting ARM: OMAP2+: Remove legacy serial.c ARM: OMAP2+: Remove legacy hsmmc.c ARM: OMAP2+: Remove legacy i2c.c platform init code ARM: OMAP2+: Remove legacy PM init ARM: OMAP2+: Remove legacy twl4030 platform init code ARM: OMAP2+: Remove legacy usb-host.c platform init code ARM: OMAP2+: Remove legacy muxing for usb-tusb6010.c ARM: OMAP2+: Remove legacy usb-musb.c platform init code ARM: OMAP2+: Remove legacy hwmod mux code ARM: OMAP2+: Remove legacy mux code ARM: OMAP2+: Remove legacy data from hwmod for omap3 ARM: OMAP2+: Remove legacy emac code ARM: OMAP2+: Remove unused platform init code and headers arch/arm/boot/dts/Makefile |5 + arch/arm/boot/dts/am3517-evm.dts | 29 + arch/arm/boot/dts/omap2420-n800.dts|8 + arch/arm/boot/dts/omap2420-n810-wimax.dts |8 + arch/arm/boot/dts/omap2420-n810.dts|8 + arch/arm/boot/dts/omap2420-n8x0-common.dtsi| 99 + arch/arm/boot/dts/omap2430-sdp.dts | 49 + arch/arm/boot/dts/omap3-ldp.dts| 231 +++ arch/arm/mach-omap1/Kconfig| 26 + arch/arm/mach-omap1/i2c.c | 83
[PATCH] ARM: omap1: clock: return 0 upon error from clk_round_rate()
clk_round_rate() should return 0 upon an error, rather than
returning a negative error code. This is because clk_round_rate() is
being changed to return an unsigned return value rather than a signed
value, since some clock sources can generate rates higher than
(2^31)-1 Hz.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
Applies on v3.13-rc3. See also:
http://marc.info/?l=linux-arm-kernelm=138542591313620w=2
arch/arm/mach-omap1/clock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 4f5fd4a084c0..ad9b620a4f30 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -250,7 +250,7 @@ long omap1_clk_round_rate_ckctl_arm(struct clk *clk,
unsigned long rate)
{
int dsor_exp = calc_dsor_exp(clk, rate);
if (dsor_exp 0)
- return dsor_exp;
+ return 0;
if (dsor_exp 3)
dsor_exp = 3;
return clk-parent-rate / (1 dsor_exp);
@@ -285,7 +285,7 @@ long omap1_round_to_table_rate(struct clk *clk, unsigned
long rate)
ref_rate = ck_ref_p-rate;
- highest_rate = -EINVAL;
+ highest_rate = 0;
for (ptr = omap1_rate_table; ptr-rate; ptr++) {
if (!(ptr-flags cpu_mask))
--
1.8.4.4
--
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 1/4] wl1251: split wl251 platform data to a separate structure
* John W. Linville linvi...@tuxdriver.com [131115 06:46]: On Thu, Nov 14, 2013 at 03:22:18PM -0800, Tony Lindgren wrote: * Sebastian Reichel s...@debian.org [131114 15:04]: On Thu, Nov 14, 2013 at 10:51:33AM -0800, Tony Lindgren wrote: [...] If this is not going into v3.13, these will cause conflicts with the mach-omap2/board-*.c files for v3.14. So it might be best to do a minimal header patch first that can be merged in by both linux-omap and wireless trees. I guess this patch is pretty minimal. It also seems to be acked by the involved Maintainers, so maybe just merge Patch 1 without the other patches? This does not solve the problem with the struct modification from the second patch, but I guess it's the more intrusive patch. Once at least the first two patches are ready, how about I queue them after -rc1 and set up an immutable branch that can be merged in by linux-omap tree and the wireless tree? That sounds reasonable to me. OK sorry it took a while, I was chasing bugs and did not get around to doing this until now. I've applied only the first two patches from the v2 set of patches later on in this thread against v3.13-rc1 into a signed tag wl1251-pdata-signed here: http://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tag/?id=wl1251-pdata-signed John, please feel free to pull the branch above also into the wireless tree so you can apply the remaining wl1251 patches from Sebastian. This way things keep working without creating merge conflicts with the linux-omap 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: [PATCH] of/platform: Fix no irq domain found errors when populating interrupts
Hi Grant, Rob,
On Sun, 24 Nov 2013, Grant Likely wrote:
On Fri, 22 Nov 2013 17:50:35 -0800, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [131122 17:16]:
* Tony Lindgren t...@atomide.com [131122 17:09]:
* Russell King - ARM Linux li...@arm.linux.org.uk [131122 16:56]:
On Fri, Nov 22, 2013 at 04:43:35PM -0800, Tony Lindgren wrote:
+ /* See of_device_resource_notify for populating
interrupts */
+ for (i = 0; i num_irq; i++, res++) {
+ res-flags = IORESOURCE_IRQ;
+ res-start = -EPROBE_DEFER;
+ res-end = -EPROBE_DEFER;
NAK. Definitely a bad idea to start introducing magic values other
into
resources. Please don't do this.
Do you have any better ideas on how to sort out this issue then?
I guess we could allocate all the resources lazily here, I'll take a look
at that.
Here's a version that allocates the resources lazily with the notifier.
Seems to boot, need to play with it a bit more though to make sure we're
not overwriting resources for any legacy devices.
Blurg. Using a notifier really feels like we don't have a good handle on
a reasonable solution yet. Basically it means we're hooking into the
driver core without /looking/ like we're hooking into the driver core. I
don't think this is any better, but I don't have a better suggestion at
the moment. :-(
Unfortunately this patch, or something that accomplishes the same results,
is somewhat high-priority for us on OMAP. OMAP37xx got prematurely
converted to DT booting, and now dynamic power management is broken:
http://marc.info/?l=linux-arm-kernelm=138658294830408w=2
Tony writes that this patch is one of the two patches needed to get things
working again:
http://marc.info/?l=linux-arm-kernelm=138660942506846w=2
Is it possible to get this patch, or something similar, merged for
v3.13-rc?
Once something like PM is broken, it's pretty easy for other broken
patches to make it into the tree, since it becomes very difficult to test
without turning into a maintainer denial-of-service attack.
- Paul
--
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: [PATCHv2 09/10] arm: dts: dra7: Add qspi device.
On Monday 09 December 2013 11:12 PM, Tony Lindgren wrote:
* Sourav Poddarsourav.pod...@ti.com [131206 06:29]:
These add device tree entry for qspi controller driver on dra7.
FYI these .dts changes need to be queued separately by Benoit and
should be posted as a seprate series in general to avoid confusion.
Ok, thanks!
I posted this for review along with other code changes.
I will post them seperately to Benoit.
Regards,
Tony
Signed-off-by: Sourav Poddarsourav.pod...@ti.com
---
v1-v2:
use MUX_MODE1 instead of numeric value
arch/arm/boot/dts/dra7-evm.dts | 32
arch/arm/boot/dts/dra7.dtsi| 13 +
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..4a57fdf 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,21 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
;
};
+
+ qspi1_pins: pinmux_qspi1_pins {
+ pinctrl-single,pins =
+ 0x4c (PIN_INPUT | MUX_MODE1) /* gpmc_a3.qspi1_cs2 */
+ 0x50 (PIN_INPUT | MUX_MODE1) /* gpmc_a4.qspi1_cs3 */
+ 0x74 (PIN_INPUT | MUX_MODE1) /* gpmc_a13.qspi1_rtclk */
+ 0x78 (PIN_INPUT | MUX_MODE1) /* gpmc_a14.qspi1_d3 */
+ 0x7c (PIN_INPUT | MUX_MODE1) /* gpmc_a15.qspi1_d2 */
+ 0x80 (PIN_INPUT | MUX_MODE1) /* gpmc_a16.qspi1_d1 */
+ 0x84 (PIN_INPUT | MUX_MODE1) /* gpmc_a17.qspi1_d0 */
+ 0x88 (PIN_INPUT | MUX_MODE1) /* qpmc_a18.qspi1_sclk */
+ 0xb8 (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs2.qspi1_cs0 */
+ 0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs3.qspi1_cs1 */
+ ;
+ };
};
i2c1 {
@@ -273,3 +288,20 @@
cpu0 {
cpu0-supply =smps123_reg;
};
+
+qspi {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 =qspi1_pins;
+
+ spi-max-frequency =4800;
+ m25p80@0 {
+ compatible = s25fl256s1;
+ spi-max-frequency =4800;
+ reg =0;
+ spi-tx-bus-width =1;
+ spi-rx-bus-width =4;
+ spi-cpol;
+ spi-cpha;
+ };
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 67275c8..b06d899 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -582,6 +582,19 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ qspi: qspi@4b30 {
+ compatible = ti,dra7xxx-qspi;
+ reg =0x4b30 0x100,0x4a002558 0x4,
+ 0x5c00 0x3ff;
+ reg-names = qspi_base, qspi_ctrlmod, qspi_mmap;
+ #address-cells =1;
+ #size-cells =0;
+ ti,hwmods = qspi;
+ num-cs =4;
+ interrupts =0 124 0x4;
+ status = disabled;
+ };
};
clocks {
--
1.7.1
--
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
--
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
[GIT PULL] wl1251 platform data changes for v3.14
The following changes since commit 736e812636ea72be444b85fa7e92554967459069: ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-wl1251 for you to fetch changes up to ce226391aec803a49b39c22d3385057c9db02f30: Merge branch 'wl1251-pdata' into omap-for-v3.14/omap3-board-removal (2013-12-09 19:39:51 -0800) Minimal changes for the wl151 platform data that would otherwise cause merge conflicts between the wireless tree and linux-omap tree. This was discussed on the mailing lists here: http://www.spinics.net/lists/linux-omap/msg99906.html Luciano Coelho (1): wl1251: split wl251 platform data to a separate structure Sebastian Reichel (1): wl1251: move power GPIO handling into the driver Tony Lindgren (1): Merge branch 'wl1251-pdata' into omap-for-v3.14/omap3-board-removal drivers/net/wireless/ti/wilink_platform_data.c | 37 +- drivers/net/wireless/ti/wl1251/sdio.c | 31 ++--- drivers/net/wireless/ti/wl1251/spi.c | 35 +++- drivers/net/wireless/ti/wl1251/wl1251.h| 2 +- include/linux/wl12xx.h | 24 +++-- 5 files changed, 97 insertions(+), 32 deletions(-) -- 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
