Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2014-01-09 06:00:11) Hi, So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Hi Tero, This approach takes care of all of my concerns with this series. Thanks for your long suffering patience on it. It seems some build errors are cropping up, so once those are fixed then I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. Regards, Mike Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 -Tero -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Hi, On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 -Tero Maintainer branches conflicts (using 3.13-rc7-dt-clks-v13): = Conflict resolution during rebase to maintainer's -14 branches: 1. (trivial) Against mike's clk-next dbdf6ff Merge branch 'clk-next-unregister' into clk-next Could not apply 2edf7ad... CLK: TI: add DT alias clock registration mechanism conflict drivers/clk/Makefile (trivial fix) 2. (manual, but changes are easy) Against Tony's omap-for-v3.14/be fc6ca98 ARM: OMAP: debug-leds: raw read and write endian fix ARM: OMAP2+: clock: use driver API instead of direct memory read/write conflicts with be changes on Tony's be branch. commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 ARM: OMAP2+: raw read and write endian fix Conflict: arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clkt_dpll.c arch/arm/mach-omap2/clkt_iclk.c arch/arm/mach-omap2/clock.c arch/arm/mach-omap2/clock36xx.c arch/arm/mach-omap2/dpll3xxx.c arch/arm/mach-omap2/dpll44xx.c Both change raw_readls - should now be just clk api instead which already does readl_relaxed etc.. If Tony feels like, then we should probably post a branch based on 'be' branch for easy merge. 3. I could not detect any merge conflict against Benoit's queued up series (but maybe he has'nt pushed everything to remote tree).. Patch verification report: == Report: http://pastebin.mozilla.org/3976492 * sparse warning added in [PATCH 06/40] CLK: ti: add support for ti divider-clock, [PATCH 10/40] clk: ti: add support for basic mux clock +drivers/clk/ti/divider.c: warning: context imbalance in 'ti_clk_divider_set_rate' - different lock contexts for basic block +drivers/clk/ti/mux.c: warning: context imbalance in 'ti_clk_mux_set_parent' - different lock contexts for basic block * checkpatch warning [PATCH 16/40] CLK: TI: add am33xx clock init file, [PATCH 18/40] CLK: TI: add omap3 clock init file WARNING: static const char * array should probably be static const char * const Boot reports: = - previous orphan clocks seem solved. - All available platforms seem to boot fine and no regression could be seen on initial view OMAP2430: 1. SDP2430 before: http://pastebin.mozilla.org/3976359 after: http://pastebin.mozilla.org/3976467 AM335x: 2. am335x-evm before: http://pastebin.mozilla.org/3976284 after: http://pastebin.mozilla.org/3976374 3. am335x-sk before: http://pastebin.mozilla.org/3976295 after: http://pastebin.mozilla.org/3976375 4. BeagleBone Black: before: http://pastebin.mozilla.org/3976321 after: http://pastebin.mozilla.org/3976441 AM3517: 5. am3517-evm before: http://pastebin.mozilla.org/3976297 after: http://pastebin.mozilla.org/3976397 6. craneboard before: http://pastebin.mozilla.org/3976322 after: http://pastebin.mozilla.org/3976452 OMAP3430: 7. ldp before: http://pastebin.mozilla.org/3976356 after: http://pastebin.mozilla.org/3976455 8. sdp3430 before: http://pastebin.mozilla.org/3976360 after: http://pastebin.mozilla.org/3976468 OMAP3630/DM3730: 9. am37x-evm before: http://pastebin.mozilla.org/3976300 after: http://pastebin.mozilla.org/3976398 10. beagle-XM before: http://pastebin.mozilla.org/3976319 after:
Re: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi, On Thursday 09 January 2014 10:54 AM, Roger Quadros wrote: Hi Marek, I have no idea what is happening there. Have you tried using device tree boot? Board file boot support would be dropped eventually. Did you try if I2C read write to the twl4030 device works and all necessary clocks/supplies are present? Kishon, do you know what is causing the USB DPLL failure there? Not sure what's causing those failures :-s -Kishon cheers, -roger On 01/09/2014 02:31 AM, Belisko Marek wrote: Any pointers? Still present in 3.13-rc7. On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote: +Kishon On 12/03/2013 11:33 PM, Belisko Marek wrote: Hi, current 3.13-rcX break usb support on gta04 board (similar to beagleboard) when booting via board file. In console we can see messages: [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5232.936096] omap_musb_mailbox: musb core is not yet ready [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock Any pointer what could cause that? (in 3.12 usb works fine) BR, marek BR, marek -- 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: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi, On Fri, Jan 10, 2014 at 6:25 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Thursday 09 January 2014 10:54 AM, Roger Quadros wrote: Hi Marek, I have no idea what is happening there. Have you tried using device tree boot? Board file boot support would be dropped eventually. Did you try if I2C read write to the twl4030 device works and all necessary clocks/supplies are present? Kishon, do you know what is causing the USB DPLL failure there? Issue was fixed. There was in 3.13-rc7 issue with unable to find phy (phy was twl4030_usb). After that issue is gone. Not sure what's causing those failures :-s -Kishon cheers, -roger On 01/09/2014 02:31 AM, Belisko Marek wrote: Any pointers? Still present in 3.13-rc7. On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros rog...@ti.com wrote: +Kishon On 12/03/2013 11:33 PM, Belisko Marek wrote: Hi, current 3.13-rcX break usb support on gta04 board (similar to beagleboard) when booting via board file. In console we can see messages: [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5232.936096] omap_musb_mailbox: musb core is not yet ready [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL clock Any pointer what could cause that? (in 3.12 usb works fine) BR, marek BR, marek BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.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 06/18] ARM: dts: omap3-overo: Enable MMC2
Hello Javier, On 01/09/2014 09:43 PM, Javier Martinez Canillas wrote: [adding Enric Balletbo to cc] Hello Florian, On Thu, Jan 9, 2014 at 1:48 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: MMC2 is used by the on-board WiFi module populated on some boards (based on Marvell Libertas 8688 SDIO). Note: currently WiFi only works on cold boot, as the module is not properly reset (missing binding for the GPIO reset). Have you looked at commit 0e9fd777 (ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO) ? If I remember correctly the LBEE1USJYC Wifi/BT combo module is basically a Marvell Libertas 8688 Wlan and Enric got soft reset working too by adding a GPIO property to the regulator for the reset GPIO. Many thanks for the pointer. In the initial version, I had a regulator like you. But now I doubt if it was correctly added to the MMC node, which could be why it was not working... I will try again. Thanks for your help! Florian -- 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
