- 23 7月, 2016 1 次提交
-
-
由 Dave Gerlach 提交于
Previously the low-level CM call internal to the _omap4_wait_target_ready/disable calls was responsible for checking for a valid clkctrl_offs. Now we must also consider the value of the prcm.omap4.flags because if HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET is set in the flags then clkctrl_offs of 0 is valid. Let's add this check into the _omap4_wait_target_ready/disable where we have access to both the clkctrl_offs and the flags values and simply return 0 without calling the low level CM call at all, which would have returned 0 anyway if the clktrl_offs was zero. Signed-off-by: NDave Gerlach <d-gerlach@ti.com> Acked-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 04 7月, 2016 2 次提交
-
-
由 Tero Kristo 提交于
The previous implementation was racy in many locations, where the current status of the clockdomain was read out, some operations were executed, and the previous status info was used afterwards to decide next state for the clockdomain. Instead, fix the implementation of the allow_idle / deny_idle APIs to properly have usecounting support. This allows clean handling internally within the clockdomain core, and simplifies the usage also within hwmod. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
With the transition to hwmod module clocks, all hwmods will have their main clocks named <hwmod_name>_mod_ck. Use this info to fetch main_clk, and use it if found. Also, if a main_clk is found based on the hwmod name, disable the direct PRCM modulemode access from hwmod. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 11 4月, 2016 1 次提交
-
-
由 Suman Anna 提交于
The omap_hwmod _enable() function can return success without setting the hwmod state to _HWMOD_STATE_ENABLED for IPs with reset lines when all of the reset lines are asserted. The omap_hwmod _idle() function also performs a similar check, but after checking for the hwmod state first. This triggers the WARN when pm_runtime_get and pm_runtime_put are invoked on IPs with all reset lines asserted. Reverse the checks for hwmod state and reset lines status to fix this. Issue found during a unbind operation on a device with reset lines still asserted, example backtrace below ------------[ cut here ]------------ WARNING: CPU: 1 PID: 879 at arch/arm/mach-omap2/omap_hwmod.c:2207 _idle+0x1e4/0x240() omap_hwmod: mmu_dsp: idle state can only be entered from enabled state Modules linked in: CPU: 1 PID: 879 Comm: sh Not tainted 4.4.0-00008-ga989d951331a #3 Hardware name: Generic OMAP5 (Flattened Device Tree) [<c0018e60>] (unwind_backtrace) from [<c0014dc4>] (show_stack+0x10/0x14) [<c0014dc4>] (show_stack) from [<c037ac28>] (dump_stack+0x90/0xc0) [<c037ac28>] (dump_stack) from [<c003f420>] (warn_slowpath_common+0x78/0xb4) [<c003f420>] (warn_slowpath_common) from [<c003f48c>] (warn_slowpath_fmt+0x30/0x40) [<c003f48c>] (warn_slowpath_fmt) from [<c0028c20>] (_idle+0x1e4/0x240) [<c0028c20>] (_idle) from [<c0029080>] (omap_hwmod_idle+0x28/0x48) [<c0029080>] (omap_hwmod_idle) from [<c002a5a4>] (omap_device_idle+0x3c/0x90) [<c002a5a4>] (omap_device_idle) from [<c0427a90>] (__rpm_callback+0x2c/0x60) [<c0427a90>] (__rpm_callback) from [<c0427ae4>] (rpm_callback+0x20/0x80) [<c0427ae4>] (rpm_callback) from [<c0427f84>] (rpm_suspend+0x138/0x74c) [<c0427f84>] (rpm_suspend) from [<c0428b78>] (__pm_runtime_idle+0x78/0xa8) [<c0428b78>] (__pm_runtime_idle) from [<c041f514>] (__device_release_driver+0x64/0x100) [<c041f514>] (__device_release_driver) from [<c041f5d0>] (device_release_driver+0x20/0x2c) [<c041f5d0>] (device_release_driver) from [<c041d85c>] (unbind_store+0x78/0xf8) [<c041d85c>] (unbind_store) from [<c0206df8>] (kernfs_fop_write+0xc0/0x1c4) [<c0206df8>] (kernfs_fop_write) from [<c018a120>] (__vfs_write+0x20/0xdc) [<c018a120>] (__vfs_write) from [<c018a9cc>] (vfs_write+0x90/0x164) [<c018a9cc>] (vfs_write) from [<c018b1f0>] (SyS_write+0x44/0x9c) [<c018b1f0>] (SyS_write) from [<c0010420>] (ret_fast_syscall+0x0/0x1c) ---[ end trace a4182013c75a9f50 ]--- While at this, fix the sequence in _shutdown() as well, though there is no easy reproducible scenario. Fixes: 747834ab ("ARM: OMAP2+: hwmod: revise hardreset behavior") Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 27 3月, 2016 1 次提交
-
-
由 Lokesh Vutla 提交于
Commit 127500cc ("ARM: OMAP2+: Only write the sysconfig on idle when necessary") talks about verification of sysconfig cache value before updating it, only during idle path. But the patch is adding the verification in the enable path. So, adding the check in a proper place as per the commit description. Not keeping this check during enable path as there is a chance of losing context and it is safe to do on idle as the context of the register will never be lost while the device is active. Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Acked-by: NTero Kristo <t-kristo@ti.com> Cc: Jon Hunter <jonathanh@nvidia.com> Cc: <stable@vger.kernel.org> # 3.12+ Fixes: commit 127500cc "ARM: OMAP2+: Only write the sysconfig on idle when necessary" [paul@pwsan.com: appears to have been caused by my own mismerge of the originally posted patch] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 07 3月, 2016 1 次提交
-
-
由 Lokesh Vutla 提交于
Introduce a dt property, ti,no-idle, that prevents an IP to idle at any point. This is to handle Errata i877, which tells that GMAC clocks cannot be disabled. Acked-by: NRoger Quadros <rogerq@ti.com> Tested-by: NMugunthan V N <mugunthanvnm@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Signed-off-by: NSekhar Nori <nsekhar@ti.com> Signed-off-by: NDave Gerlach <d-gerlach@ti.com> Acked-by: NRob Herring <robh@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 04 12月, 2015 1 次提交
-
-
由 Tony Lindgren 提交于
We want to be able to probe a few selected device drivers before hwmod code populates the clocks in omap_hwmod_setup_all(). This allows us to convert most of the clock drivers into regular device drivers. We only need a few minimal clock drivers early for the system timers to select between the 32KiHz clock and the high frequency oscillator. With these changes, initializing the clock drivers can be just done at core_initcall time with something like: np = of_find_node_by_name(NULL, "plls"); if (np) of_platform_populate(np, NULL, NULL, NULL); And then these clocks will be available for the interconnect code to use. Having most of the clock drivers being regular device drivers allows us to use the nice things like devm_* functions and dev_err and dev_dbg. As an extra bonus, this also allows us to develop the clock drivers for new SoCs as loadable modules initially for cases where we can boot up the system based on the bootloader configured clocks. To do this, let's change the core_initcalls to postcore_initcall under mach-omap2. Cc: Felipe Balbi <balbi@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 13 11月, 2015 1 次提交
-
-
由 Peter Ujfalusi 提交于
Some module needs more than one functional clock in order to be accessible, like the McASPs found in DRA7xx family. This flag will indicate that the opt_clks need to be handled at the same time as the main_clk for the given hwmod, ensuring that all needed clocks are enabled before we try to access the module's address space. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 24 7月, 2015 1 次提交
-
-
由 Tony Lindgren 提交于
Let's add minimal set of dm814x hwmods to have a bootable system. Cc: Matthijs van Duin <matthijsvanduin@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 7月, 2015 1 次提交
-
-
由 Roger Quadros 提交于
For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so _find_mpu_rt_port(oh) will return NULL thus preventing ready state check on those modules after the module is enabled. This can potentially cause a bus access error if the module is accessed before the module is ready. Fix this by unconditionally calling _init_mpu_rt_base() during hwmod _init(). Do ioremap only if we need SYSC access. Eventhough _wait_target_ready() check doesn't really need MPU RT port but just the PRCM registers, we still mandate that the hwmod must have an MPU RT port if ready state check needs to be done. Else it would mean that the module is not accessible by MPU so there is no point in waiting for target to be ready. e.g. this fixes the below DCAN bus access error on AM437x-gp-evm. [ 16.672978] ------------[ cut here ]------------ [ 16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x234/0x35c() [ 16.687946] 44000000.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read): Data Access in User mode during Functional access [ 16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts c_can dc [ 16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 3.14.26-02561-gf733aa036398 #180 [ 16.739747] Backtrace: [ 16.742336] [<c0011108>] (dump_backtrace) from [<c00112a4>] (show_stack+0x18/0x1c) [ 16.750285] r6:00000093 r5:00000009 r4:eab5b8a8 r3:00000000 [ 16.756252] [<c001128c>] (show_stack) from [<c05a4418>] (dump_stack+0x20/0x28) [ 16.763870] [<c05a43f8>] (dump_stack) from [<c0037120>] (warn_slowpath_common+0x6c/0x8c) [ 16.772408] [<c00370b4>] (warn_slowpath_common) from [<c00371e4>] (warn_slowpath_fmt+0x38/0x40) [ 16.781550] r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210 [ 16.788626] [<c00371b0>] (warn_slowpath_fmt) from [<c027fa94>] (l3_interrupt_handler+0x234/0x35c) [ 16.797968] r3:ed0cd480 r2:c0730508 [ 16.801747] [<c027f860>] (l3_interrupt_handler) from [<c0063758>] (handle_irq_event_percpu+0x54/0x1bc) [ 16.811533] r10:ed005600 r9:c084855b r8:0000002a r7:00000000 r6:00000000 r5:0000002a [ 16.819780] r4:ed0e6d80 [ 16.822453] [<c0063704>] (handle_irq_event_percpu) from [<c00638f0>] (handle_irq_event+0x30/0x40) [ 16.831789] r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6:00000000 r5:0000002a [ 16.840052] r4:ed005600 [ 16.842744] [<c00638c0>] (handle_irq_event) from [<c00661d8>] (handle_fasteoi_irq+0x74/0x128) [ 16.851702] r4:ed005600 r3:00000000 [ 16.855479] [<c0066164>] (handle_fasteoi_irq) from [<c0063068>] (generic_handle_irq+0x28/0x38) [ 16.864523] r4:0000002a r3:c0066164 [ 16.868294] [<c0063040>] (generic_handle_irq) from [<c000ef60>] (handle_IRQ+0x38/0x8c) [ 16.876612] r4:c081c640 r3:00000202 [ 16.880380] [<c000ef28>] (handle_IRQ) from [<c00084f0>] (gic_handle_irq+0x30/0x5c) [ 16.888328] r6:eab5ba38 r5:c0804460 r4:fa24010c r3:00000100 [ 16.894303] [<c00084c0>] (gic_handle_irq) from [<c05a8d80>] (__irq_svc+0x40/0x50) [ 16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80) [ 16.907499] ba20: 00000000 00000006 [ 16.916108] ba40: fa1d0000 fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 bf011420 eb2b6960 [ 16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 600f0013 ffffffff [ 16.933317] r7:eab5ba6c r6:ffffffff r5:600f0013 r4:bf07702c [ 16.939317] [<bf077000>] (c_can_plat_read_reg_aligned_to_16bit [c_can_platform]) from [<bf035220>] (c_can_get_berr_counter+0x38/0x64 [c_can]) [ 16.952696] [<bf0351e8>] (c_can_get_berr_counter [c_can]) from [<bf010294>] (can_fill_info+0x124/0x15c [can_dev]) [ 16.963480] r5:ec8c9740 r4:ed3d3000 [ 16.967253] [<bf010170>] (can_fill_info [can_dev]) from [<c0502fa8>] (rtnl_fill_ifinfo+0x58c/0x8fc) [ 16.976749] r6:ec8c9740 r5:ed3d3000 r4:eb2b6780 [ 16.981613] [<c0502a1c>] (rtnl_fill_ifinfo) from [<c0503408>] (rtnl_dump_ifinfo+0xf0/0x1dc) [ 16.990401] r10:ec8c9740 r9:00000000 r8:00000000 r7:00000000 r6:ebd4d1b4 r5:ed3d3000 [ 16.998671] r4:00000000 [ 17.001342] [<c0503318>] (rtnl_dump_ifinfo) from [<c050e6e4>] (netlink_dump+0xa8/0x1e0) [ 17.009772] r10:00000000 r9:00000000 r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 r5:ec8c9740 [ 17.018050] r4:ebd4d000 [ 17.020714] [<c050e63c>] (netlink_dump) from [<c050ec10>] (__netlink_dump_start+0x104/0x154) [ 17.029591] r6:eab5bd34 r5:ec8c9980 r4:ebd4d000 [ 17.034454] [<c050eb0c>] (__netlink_dump_start) from [<c0505604>] (rtnetlink_rcv_msg+0x110/0x1f4) [ 17.043778] r7:00000000 r6:ec8c9980 r5:00000f40 r4:ebf3e6c0 [ 17.049743] [<c05054f4>] (rtnetlink_rcv_msg) from [<c05108e8>] (netlink_rcv_skb+0xb4/0xc8) [ 17.058449] r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0 [ 17.065534] [<c0510834>] (netlink_rcv_skb) from [<c0504134>] (rtnetlink_rcv+0x24/0x2c) [ 17.073854] r6:ebd4d000 r5:00000014 r4:ec8c9980 r3:c0504110 [ 17.079846] [<c0504110>] (rtnetlink_rcv) from [<c05102ac>] (netlink_unicast+0x180/0x1ec) [ 17.088363] r4:ed0c6800 r3:c0504110 [ 17.092113] [<c051012c>] (netlink_unicast) from [<c0510670>] (netlink_sendmsg+0x2ac/0x380) [ 17.100813] r10:00000000 r8:00000008 r7:ec8c9980 r6:ebd4d000 r5:eab5be70 r4:eab5bee4 [ 17.109083] [<c05103c4>] (netlink_sendmsg) from [<c04dfdb4>] (sock_sendmsg+0x90/0xb0) [ 17.117305] r10:00000000 r9:eab5a000 r8:becdda3c r7:0000000c r6:ea978400 r5:eab5be70 [ 17.125563] r4:c05103c4 [ 17.128225] [<c04dfd24>] (sock_sendmsg) from [<c04e1c28>] (SyS_sendto+0xb8/0xdc) [ 17.136001] r6:becdda5c r5:00000014 r4:ecd37040 [ 17.140876] [<c04e1b70>] (SyS_sendto) from [<c000e680>] (ret_fast_syscall+0x0/0x30) [ 17.148923] r10:00000000 r8:c000e804 r7:00000122 r6:becdda5c r5:0000000c r4:becdda5c [ 17.157169] ---[ end trace 2b71e15b38f58bad ]--- Fixes: 6423d6df ("ARM: OMAP2+: hwmod: check for module address space during init") Signed-off-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: <stable@vger.kernel.org>
-
- 21 7月, 2015 1 次提交
-
-
由 Stephen Boyd 提交于
These files use the consumer API, so include clk.h explicitly. Acked-by: NTero Kristo <t-kristo@ti.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
-
- 16 7月, 2015 1 次提交
-
-
由 Lokesh Vutla 提交于
Some IP blocks like RTC, needs an additional setting for writing to its registers. This is to prevent any spurious writes from changing the register values. This patch adds optional lock and unlock function pointers to the IP block's hwmod data. These unlock and lock function pointers are called by hwmod code before and after writing sysconfig registers. Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> [paul@pwsan.com: fixed indentation level to conform with the rest of the structure members] Reviewed-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 02 6月, 2015 1 次提交
-
-
由 Pali Rohár 提交于
Without this patch function pm_runtime_get_sync() returns 0 even when some omap subfunction fails. This patch properly propagate error codes from omap functions back to caller. This patch fix problem, when loading omap-aes driver in qemu cause kernel oops. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> [paul@pwsan.com: fix a checkpatch warning] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 09 5月, 2015 2 次提交
-
-
由 Tero Kristo 提交于
The reset code functionality is mostly a copy paste between OMAP4+ and AM33xx+. Re-use the omap4 code where possible, and just keep the special implementation for de-asserting the hardreset lines for AM33xx, as AM33xx+ devices have slightly different register layouts compared to OMAP4+. This patch also fixes the hardreset issues faced on AM43xx. Signed-off-by: NTero Kristo <t-kristo@ti.com> Reported-by: NDave Gerlach <d-gerlach@ti.com> Reported-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Tero Kristo 提交于
AM43xx has slightly different reset register layout compared to OMAP4+, with varying status bit shifts and status register offsets. Current code assumes static offsets and identical status / reset control bit shifts, which is wrong. This patch adds PRM core support for passing the actual implementations from hwmod code. AM43xx mappings will be fixed in subsequent patch. Signed-off-by: NTero Kristo <t-kristo@ti.com> Reported-by: NDave Gerlach <d-gerlach@ti.com> Reported-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 02 3月, 2015 1 次提交
-
-
由 Tero Kristo 提交于
Deasserting hardreset increases the usecount for the hwmod parent clockdomain always, however usecount is only decreased at end in certain error cases. This causes software supervised clockdomains to remain always on, preventing idle. Fixed by always releasing the hwmods clockdomain parent when exiting the function. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NCarlos Hernandez <ceh@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 26 2月, 2015 1 次提交
-
-
由 Peter Ujfalusi 提交于
Add struct lock_class_key to omap_hwmod struct and use it to set unique lockdep class per hwmod. This will ensure that lockdep will know that each omap_hwmod->_lock should be treated as separate class and will not give false warning about deadlock or other issues due to nested use of hwmods. DRA7x's ATL hwmod is one example for this since McASP can select ATL clock as functional clock, which will trigger nested oh->_lock usage. This will trigger false warning from lockdep validator as it is dealing with classes and for it all hwmod clocks are the same class. Suggested-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 27 1月, 2015 1 次提交
-
-
由 Tony Lindgren 提交于
Add minimal hwmod support that works at least on dm8168. This is based on the code in the earlier TI CDP tree, and an earlier patch by Aida Mynzhasova <aida.mynzhasova@skitlab.ru>. I've set up things to work pretty much the same way as for am33xx. We are basically using cm33xx.c with a different set of clocks and clockdomains. This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches published at: http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html Cc: Aida Mynzhasova <aida.mynzhasova@skitlab.ru> Cc: Brian Hutchinson <b.hutchman@gmail.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 21 1月, 2015 1 次提交
-
-
由 Lokesh Vutla 提交于
Fixed pr_debug to pr_err when hwmod returns an error when enabling a module. Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Acked-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 18 1月, 2015 1 次提交
-
-
由 Marc Zyngier 提交于
Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain") changed the GIC driver to use a non-legacy IRQ domain on DT platforms. This patch assumes that DT-driven systems are getting all of their interrupts from device tree. Turns out that OMAP has quite a few hidden gems, and still uses hardcoded interrupts despite having fairly complete DTs. This patch attempts to work around these by offering a translation method that can be called directly from the hwmod code, if present. The same hack is sprinkled over PRCM and TWL. It isn't pretty, but it seems to do the job without having to add more hacks to the interrupt controller code. Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432). Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com> Acked-by: NNishanth Menon <nm@ti.com> [tony@atomide.com: updated to fix make randconfig issue] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 08 1月, 2015 1 次提交
-
-
由 Rickard Strandqvist 提交于
Removes some functions that are not used anywhere: omap_hwmod_pad_route_irq() omap_hwmod_no_setup_reset() omap_hwmod_read_hardreset() omap_hwmod_del_initiator_dep() omap_hwmod_enable_clocks() omap_hwmod_reset() omap_hwmod_ocp_barrier() omap_hwmod_disable_clocks() omap_hwmod_add_initiator_dep() This was partially found by using a static code analysis program called cppcheck. Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 20 11月, 2014 1 次提交
-
-
由 Tomi Valkeinen 提交于
Add parent_hwmod pointer to omap_hwmod. This can be set to point to a "parent" hwmod that needs to be enabled for the "child" hwmod to work. This is used at hwmod setup time: when doing the initial setup and reset, first enable the parent hwmod, and after setup and reset is done, restore the parent hwmod to postsetup_state. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: NArchit Taneja <archit.taneja@gmail.com> [paul@pwsan.com: add kerneldoc documentation for parent_hwmod; note that it is a temporary workaround] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 14 11月, 2014 1 次提交
-
-
由 Felipe Balbi 提交于
ml->node and sl->node are currently initialized by means of INIT_LIST_HEAD(). That initialiation is followed by a list_add() call. Looking at what both these functions do we will have: ml->node.next = &ml->node; ml->node.prev = &ml->node; oi->master->master_ports.next.prev = &ml->node; ml->node.next = &oi->master->master_ports.next; ml->node.prev = &oi->master->master_ports; oi->master->master_ports.next = &ml->node; from this, it's clear that both INIT_LIST_HEAD() calls are unnecessary and can be safely removed. Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 27 10月, 2014 12 次提交
-
-
由 Tero Kristo 提交于
This adds a generic API for reconfiguring the I/O chain. The implementation will call the SoC specific function registered during init time. The SoC specific reconfigure functions are also made static, as they don't need to be accessed outside the PRM driver itself. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> [tony@atomide.com: updated for recent omap3 prcm fixes] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
cminst44xx.h will be removed, thus move the public APIs to cm44xx.h header. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
PRM driver now has a generic API for checking hardreset status. SoC specific support functions are registered through the prm_ll_data. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
PRM driver now has a generic API for deasserting hardware resets. SoC specific support functions are registered through the prm_ll_data. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
PRM driver now has a generic API for asserting hardware resets. SoC specific support functions are registered through the prm_ll_data. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
AM43xx is using OMAP4+ PRM driver, so it should be using the corresponding hardreset ops from the hwmod also. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
These are now identical with the OMAP4 implementations, so use the OMAP4 versions and remove the AM33xx ones. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
Adds a generic CM driver API for enabling/disabling modules. The SoC specific implementations are registered through cm_ll_data. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
Adds a generic CM driver API for waiting module to enter idle / standby. The SoC specific implementations are registered through cm_ll_data. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
This patch consolidates the parameters provided for the SoC specific cm_*_wait_module_ready calls, adds the missing cm_ll_data function pointers and uses the now generic call from the mach-omap2 board code. SoC specific *_wait_module_ready calls are also made static so they can only be accessed through the generic CM driver API only. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
This is not needed for anything. This also eases the consolidation of the wait_module_ready / wait_module_idle calls behind a generic CM driver API by reducing the number of needed parameters. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tero Kristo 提交于
The implementation on these is identical, so no need to have them separate. Signed-off-by: NTero Kristo <t-kristo@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 19 9月, 2014 1 次提交
-
-
由 Joe Perches 提交于
Use the more common pr_warn. Other miscellanea: o Realign arguments Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 18 9月, 2014 1 次提交
-
-
由 Tony Lindgren 提交于
Commit cc824534 ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled") fixed issues with hung UART wake-up events by calling _reconfigure_io_chain() when MUSB is connected or disconnected. As pointed out by Paul Walmsley, we may need to also call _reconfigure_io_chain() in other cases, so it should be a separate flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul. Reviewed-by: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 17 9月, 2014 1 次提交
-
-
由 Tony Lindgren 提交于
We are getting "PRM: I/O chain clock line assertion timed out" errors on early omaps for device tree based booting. This is because we are unconditionally calling reconfigure_io_chain while legacy booting has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c. For device tree based booting, we are calling reconfigure_io_chain unconditionally from pinctrl framework. So we need to add a check for omap3_has_io_chain_ctrl() to avoid the errors for trying to access a register that does not exist. For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration" just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get added until in es3.1 probaly to fix issues with flakey wake-up events. We are doing proper checks for ST_IO_CHAIN already in id.c and with omap3_has_io_chain_ctrl(). For more information, see also commit b02b9172 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection"). Let's fix the issue by selecting the right function during init for reconfigure_io_chain depending on the omap revision. For es3.0 and earlier we need to just toggle EN_IO. By doing this, we can move the check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain. Thanks to Paul Walmsley and Nishanth Menon for help with debugging the issue. Fixes: 30a69ef7 ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap") Cc: Kevin Hilman <khilman@kernel.org> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <t-kristo@ti.com> Reviewed-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 28 8月, 2014 1 次提交
-
-
由 Rajendra Nayak 提交于
To deal with IPs which are specific to dra74x and dra72x, maintain seperate ocp interface lists, while keeping the common list for all common IPs. Move USB OTG SS4 to dra74x only list since its unavailable in dra72x and is giving an abort during boot. The dra72x only list is empty for now and a placeholder for future hwmod additions which are specific to dra72x. Fixes: d904b38d ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss") Reported-by: NKeerthy <j-keerthy@ti.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Tested-by: NNishanth Menon <nm@ti.com> [paul@pwsan.com: fixed comment style to conform with CodingStyle] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 26 8月, 2014 1 次提交
-
-
由 Tony Lindgren 提交于
Looks like MUSB cable removal can cause wake-up interrupts to stop working for device tree based booting at least for UART3 even as nothing is dynamically remuxed. This can be fixed by calling reconfigure_io_chain() for device tree based booting in hwmod code. Note that we already do that for legacy booting if the legacy mux is configured. My guess is that this is related to UART3 and MUSB ULPI hsusb0_data0 and hsusb0_data1 support for Carkit mode that somehow affect the configured IO chain for UART3 and require rearming the wake-up interrupts. In general, for device tree based booting, pinctrl-single calls the rearm hook that in turn calls reconfigure_io_chain so calling reconfigure_io_chain should not be needed from the hwmod code for other events. So let's limit the hwmod rearming of iochain only to HWMOD_FORCE_MSTANDBY where MUSB is currently the only user of it. If we see other devices needing similar changes we can add more checks for it. Cc: Paul Walmsley <paul@pwsan.com> Cc: stable@vger.kernel.org # v3.16 Signed-off-by: NTony Lindgren <tony@atomide.com>
-