3d0cb73e9c85e60206ea9d5191bc0b9a0c4c8a99 |
|
13-Sep-2014 |
Joe Perches <joe@perches.com> |
arm: mach-omap2: Convert pr_warning to pr_warn Use the more common pr_warn. Other miscellanea: o Realign arguments Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
6a08b11adda53b89d32d4becac4d7f062a0e2d99 |
|
18-Sep-2014 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN Commit cc824534d4fe ("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: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
7db143b89137de06ed289cf8b302f3bbbc5baa1f |
|
17-Sep-2014 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP3: Fix I/O chain clock line assertion timed out error 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 b02b917211d5 ("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: 30a69ef785e8 ("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: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
f7f7a29bf0cf25af23f37e5b5bf1368b85705286 |
|
28-Aug-2014 |
Rajendra Nayak <rnayak@ti.com> |
ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists 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: d904b38df0db13 ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss") Reported-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Nishanth Menon <nm@ti.com> [paul@pwsan.com: fixed comment style to conform with CodingStyle] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
cc824534d4fef0e46e4486d5c1e10d3c6b1ebadc |
|
26-Aug-2014 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: hwmod: Rearm wake-up interrupts for DT when MUSB is idled 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: Tony Lindgren <tony@atomide.com>
|
98bbc114bfa0ea1da31e230050b437e19e49e2b3 |
|
16-Jun-2014 |
Dave Gerlach <d-gerlach@ti.com> |
ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX am43xx reset register layout is more similar to am33xx than omap4 so use the am33xx functions for hwmod hardreset soc_ops rather than the currently used omap4 functions. Without this, assert_hardreset and deassert_hardreset will not work on am43xx. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> [paul@pwsan.com: fixed build errors for an AM43xx-only Kconfig] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
edfaf05c2fcb853fcf35f12aeb9c340f5913337f |
|
15-Apr-2014 |
Victor Kamensky <victor.kamensky@linaro.org> |
ARM: OMAP2+: raw read and write endian fix All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
3d36ad7e7a9be0d130c862727a052ed279046437 |
|
14-Mar-2014 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: hwmod: fix missing braces in _init() Bug was introduced by commit 'f92d959: ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT' There were 2 versions of the patch posted which resulted in the above commit. While v1 [1] had the bug, v2 [2] had it fixed. However v1 apparently seemed to have been pulled in by mistake introducing the bug. Given of_find_property() does return NULL when the node passed is NULL, it did not introduce any functional issues as such, just the fact that the second if check was executed unnecessarily. [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg94220.html [2] http://www.spinics.net/lists/linux-omap/msg98490.html Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Fixes: f92d9597f781f6a5a39c73dc71604bd8a21c5299 ("ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT") Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
01142519ffc0734436f26b01aeed37a915dece05 |
|
05-Feb-2014 |
Illia Smyrnov <illia.smyrnov@globallogic.com> |
ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4 Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced softreset bit cleaning right after set one. It is caused L3 error for OMAP4 ISS because ISS register write occurs when ISS reset process is in progress. Avoid this situation by cleaning softreset bit later, when reset process is successfully finished. Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b6cb5bab263791d09abe88f24df6c2da53415320 |
|
22-Jan-2014 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
arch/arm/mach-omap2/omap_hwmod.c: use memblock apis for early memory allocations Switch to memblock interfaces for early memory allocator instead of bootmem allocator. No functional change in beahvior than what it is in current code from bootmem users points of view. Archs already converted to NO_BOOTMEM now directly use memblock interfaces instead of bootmem wrappers build on top of memblock. And the archs which still uses bootmem, these new apis just fallback to exiting bootmem APIs. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Paul Walmsley <paul@pwsan.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tejun Heo <tj@kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
0385c58207771efed179670549573fb779c15dc9 |
|
17-Jul-2013 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP3: hwmod: initialize clkdm from clkdm_name DT clocks are mostly missing clkdm info now, and this causes an issue with counter32k which makes its slave idlemode wrong and prevents core idle. Fixed by initializing the hwmod clkdm pointers for omap3 also which makes sure the clkdm flag matching logic works properly. This patch also changes the return value for _init_clkdm to 0 for incorrect clkdm_name, as this a warning, not a fatal error. Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
924f9498acb004d8cb704a008f1060fad604ccca |
|
11-Jul-2013 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP: hwmod: fix an incorrect clk type cast with _get_clkdm If the main clock for a hwmod is of basic clock type, it is illegal to type cast this to clk_hw_omap and will result in bogus data. Fixed by checking the clock flags before attempting the type cast. Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
0e7dc862cf687234ed1b01a6b2461b782ea0bca0 |
|
09-Dec-2013 |
Nishanth Menon <nm@ti.com> |
ARM: OMAP2+: hwmod: Fix usage of invalid iclk / oclk when clock node is not present commit dc75925d(OMAP: hwmod: Fix the missing braces) introduced missing braces, however, we just set return result if clk_get fail and we populate the error pointer in clk pointer and pass it along to clk_prepare. This is wrong. The intent seems to be retry remaining clocks if they are available and warn the ones we cant find clks for. With the current logic, we see the following crash: omap_hwmod: l3_main: cannot clk_get interface_clk emac_ick Unable to handle kernel NULL pointer dereference at virtual address 00000032 pgd = c0004000 [00000032] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-00044-gcc9fd5a-dirty #19 task: ce0c3440 ti: ce0c4000 task.ti: ce0c4000 PC is at __clk_prepare+0x10/0x74 LR is at clk_prepare+0x14/0x24 <snip> [<c044d59c>] (__clk_prepare+0x10/0x74) from [<c044d9b0>] (clk_prepare+0x14/0x24) [<c044d9b0>] (clk_prepare+0x14/0x24) from [<c077d8c4>] (_init+0x24c/0x3bc) [<c077d8c4>] (_init+0x24c/0x3bc) from [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) [<c0027328>] (omap_hwmod_for_each+0x34/0x5c) from [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) [<c077dfa0>] (__omap_hwmod_setup_all+0x24/0x40) from [<c0008928>] (do_one_initcall+0x38/0x168) [<c0008928>] (do_one_initcall+0x38/0x168) from [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) [<c0771be8>] (kernel_init_freeable+0xfc/0x1cc) from [<c0521064>] (kernel_init+0x8/0x110) [<c0521064>] (kernel_init+0x8/0x110) from [<c000e568>] (ret_from_fork+0x14/0x2c) Code: e92d4038 e2504000 01a05004 0a000005 (e5943034) So, just warn and continue instead of proceeding and crashing, with missing clock nodes/bad data, we will eventually fail, however we should now have enough information to identify the culprit. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
313a76ee11cda6700548afe68499ef174a240688 |
|
09-Dec-2013 |
Roger Quadros <rogerq@ti.com> |
ARM: OMAP2+: hwmod: Fix SOFTRESET logic In _ocp_softreset(), after _set_softreset() + write_sysconfig(), the hwmod's sysc_cache will always contain SOFTRESET bit set so all further writes to sysconfig using this cache will initiate a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like platforms that have RESET_DONE status in the SYSSTATUS register and so the the SOFTRESET bit in SYSCONFIG is not automatically cleared. It is not a problem for OMAP4 like platforms that indicate RESET completion by clearing the SOFTRESET bit in the SYSCONFIG register. This repeated SOFTRESET is undesired and was the root cause of USB host issues on OMAP3 platforms when hwmod was allowed to do the SOFTRESET for the USB Host module. To fix this we clear the SOFTRESET bit and update the sysconfig register + sysc_cache using write_sysconfig(). Signed-off-by: Roger Quadros <rogerq@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM [paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
5e863c561048252bb230d2f9daeed9fbe2705b41 |
|
06-Dec-2013 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Fix overwriting hwmod data with data from device tree We have some device tree properties where the ti,hwmod have multiple values: am33xx.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; am4372.dtsi: ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; dra7.dtsi: ti,hwmods = "l3_main_1", "l3_main_2"; omap3.dtsi: ti,hwmods = "mcbsp2", "mcbsp2_sidetone"; omap3.dtsi: ti,hwmods = "mcbsp3", "mcbsp3_sidetone"; omap4.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3"; omap5.dtsi: ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3"; That's not correct way of doing things in this case because these are separate devices with their own address space, interrupts, SYSCONFIG registers and can set their PM states independently. So they should all be fixed up to be separate devices in the .dts files. We also have the related data removed for at least omap4 in commit 3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so that data is wrongly initialized as null data. So we need to fix two bugs: 1. We are only checking the first entry of the ti,hwmods property This means that we're only initializing the first hwmods entry instead of the ones listed in the ti,hwmods property. 2. We are only checking the child nodes, not the nodes themselves This means that anything listed at OCP level is currently just ignored and unitialized and at least the omap4 case, with the legacy data missing from the hwmod. Fix both of the issues by using an index to the ti,hwmods property and changing the hwmod lookup function to also check the current node for ti,hwmods property instead of just the children. While at it, let's also add some warnings for the bad data so it's easier to fix. Cc: "Benoît Cousson" <bcousson@baylibre.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
c8b428a5b16bf02ae0290511466e0d15a9f65b35 |
|
12-Oct-2013 |
Afzal Mohammed <afzal@ti.com> |
ARM: OMAP2+: hwmod: AM43x operations Reuse OMAP4 operations on AM43x. Context related ops are not used on AM43x, as this would not add value when using DT and AM43x is DT only boot. This additionally helps not to add context register offset for each hwmod. Signed-off-by: Ambresh K <ambresh@ti.com> Signed-off-by: Afzal Mohammed <afzal@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
f92d9597f781f6a5a39c73dc71604bd8a21c5299 |
|
09-Oct-2013 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT Now that we have DT bindings to specify which devices should not be reset and idled during init, make hwmod extract the information (and store them in internal flags) from Device tree. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6423d6df1440a8acfc2f375d7cbc4cd66c2e6910 |
|
09-Oct-2013 |
Suman Anna <s-anna@ti.com> |
ARM: OMAP2+: hwmod: check for module address space during init The hwmod init sequence involves initializing and idling all the hwmods during bootup. If a module class has sysconfig, the init sequence utilizes the module register base for performing any sysc configuration. The module address space is being removed from hwmod database and retrieved from the <reg> property of the corresponding DT node. If a hwmod does not have its corresponding DT node defined and the memory address space is not defined in the corresponding omap_hwmod_ocp_if, then the module register target address space would be NULL and any sysc programming would result in a NULL pointer dereference and a kernel boot hang. Handle this scenario by checking for a valid module address space during the _init of each hwmod, and leaving it in the registered state if no module register address base is defined in either of the hwmod data or the DT data. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> [paul@pwsan.com: use -ENXIO rather than -ENOMEM to indicate a missing address space error; fixed checkpatch.pl problem] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
127500ccb766f0e963436e25ddd57be8f1695498 |
|
23-Aug-2013 |
Jon Hunter <jon-hunter@ti.com> |
ARM: OMAP2+: Only write the sysconfig on idle when necessary Currently, whenever we idle a device _idle_sysc() is called and writes to the devices SYSCONFIG register to set the idle mode. A lot devices are using the smart-idle mode and so the write to the SYSCONFIG register is programming the same value that is already stored in the register. Writes to the devices SYSCONFIG register can be slow, for example, writing to the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can take ~100us. Furthermore, during boot on an OMAP4430 panda board, I see that there are 100 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write the SYSCONFIG register with a new value. Therefore, to avoid unnecessary writes to device SYSCONFIG registers when idling the device, only write the value if the value has changed. It should be safe to do this on idle as the context of the register will never be lost while the device is active. Verified that suspend, CORE off and retention states are working with this change on OMAP3430 Beagle board. Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
debcd1f81f9ef632a24b7b7a9367363fa62fbceb |
|
02-Jul-2013 |
Rajendra Nayak <rnayak@ti.com> |
ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 The soc_ops for dra7xx devices can be completed reused from the ones used for omap4 and omap5 devices. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: R Sricharan <r.sricharan@ti.com>
|
130142d91467e8a07f3a863db369225a89e84d75 |
|
05-Jul-2013 |
Afzal Mohammed <afzal@ti.com> |
ARM: OMAP2+: hwmod: rt address space index for DT Address space is being removed from hwmod database and DT information in <reg> property is being used. Currently the 0th index of device address space is used to map for register target address. This is not always true, eg. cpgmac has it's sysconfig in second address space. Handle it by specifying index of device address space to be used for register target. As default value of this field would be zero with static initialization, existing behaviour of using first address space for register target while using DT would be kept as such. Signed-off-by: Afzal Mohammed <afzal@ti.com> Tested-by: Mugunthan V N <mugunthanvnm@ti.com> [paul@pwsan.com: use u8 rather than int to save memory] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
3260c76055afc6c9396e5ad9f9e599505ea8891f |
|
15-May-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: OMAP2+: hwmod: Remove sysc slave idle and auto idle apis With the OMAP serial driver sysc cleanup patches in this series, we can now remove the hwmod external apis for sysc fiddling. While at this, also remove unused sysc auto idle api from hwmod code. Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by: Rajendra nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
ca43ea345de96dc214be790b6cebedbdfe110b63 |
|
15-May-2013 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Add a new flag to handle SIDLE in SWSUP only in active Some IPs (like UART) need the sidle mode to be controlled in SW only while they are active. Once they go inactive, they need the IP to be put back in HW control so they are also wakeup capable. The flag HWMOD_SWSUP_SIDLE takes care of IPs which need the sidle mode to be *always* controlled in SWSUP. We now have a need to control IPs sidle mode in SWSUP only while its active. So define a new flag 'HWMOD_SWSUP_SIDLE_ACT' to help the framework know about these new IP requirements. Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
35513171eed4d7245e81d926d311e74f3dca06f3 |
|
15-May-2013 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Fix sidle programming in _enable_sysc()/_idle_sysc() _enable_sysc() and _idle_sysc() handle the midle mode programming correctly and program HWMOD_IDLEMODE_SMART or HWMOD_IDLEMODE_SMART_WKUP respectively for supported IPs (The ones which support hardware controlled midle modes) However the same programming logic is missing when it comes to sidle mode programming. Here they seem to just set HWMOD_IDLEMODE_SMART (Again for the ones which support hardware controlled sidle modes) This problem was hidden due to the fact that a call to _enable_wakeup() in those same functions would overwrite the idlemodes and program them correctly (to HWMOD_IDLEMODE_SMART_WKUP in the supported cases) So fix the sidlemode handling correctly in these functions and handle the _enable_wakeup() for SIDLEMODE supported IPs same as the way its handled for MIDLEMODE supported ones. Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
0f497039276fa2ca2ca324236848bb15c8c775dc |
|
16-May-2013 |
jean-philippe francois <jp.francois@cynove.com> |
ARM: OMAP: fix __init section mismatch for _enable_preprogram _enable_preprogram is marked as __init, but is called from _enable which is not. Without this patch, the board oopses after init. Tested on custom hardware and on beagle board xM. Otherwise we can get: Unable to handle kernel paging request at virtual address 000b0012 pgd = cf968000 *pgd=8fb06831, *pte=00000000, *ppte=00000000 PREEMPT ARM Modules linked in: CPU: 0 Not tainted (3.9.0 #2) PC is at _enable_preprogram+0x1c/0x24 LR is at omap_hwmod_enable+0x34/0x60 psr: 80000093 sp : cf95de08 ip : 00002de5 fp : bec33d4c r10: 00000000 r9 : 00000002 r8 : b6dd2c78 r7 : 00000004 r6 : 00000000 r5 : a0000013 r4 : cf95c000 r3 : 00000000 r2 : b6dd2c7c r1 : 00000000 r0 : 000b0012 Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8f968019 DAC: 00000015 Process otpcmd (pid: 607, stack limit = 0xcf95c230) Stack: (0xcf95de08 to 0xcf95e000) de00: 00000001 cf91f840 00000000 c001d6fc 00000002 cf91f840 de20: cf8f7e10 c001de54 cf8f7e10 c001de78 c001de68 c01d5e80 00000000 cf8f7e10 de40: cf8f7e10 c01d5f28 cf8f7e10 c0530d30 00000000 c01d6f28 00000000 c0088664 de60: b6ea1000 cfb05284 cf95c000 00000001 cf95c000 60000013 00000001 cf95dee4 de80: cf870050 c01d7308 cf870010 cf870050 00000001 c0278b14 c0526f28 00000000 dea0: cf870050 ffff8e18 00000001 cf95dee4 00000000 c0274f7c cf870050 00000001 dec0: cf95dee4 cf1d8484 000000e0 c0276464 00000008 cf9c0000 00000007 c0276980 dee0: cf9c0000 00000064 00000008 cf1d8404 cf1d8400 c01cc05c 0000270a cf1d8504 df00: 00000023 cf1d8484 00000007 c01cc670 00000bdd 00000001 00000000 cf449e60 df20: cf1dde70 cf1d8400 bec33d18 cf1d8504 c0246f00 00000003 cf95c000 00000000 df40: bec33d4c c01cd078 00000003 cf1d8504 00000081 c01cbcb8 bec33d18 00000003 df60: bec33d18 c00a9034 00002000 c00a9c68 cf92fe00 00000003 c0246f00 cf92fe00 df80: 00000000 c00a9cb0 00000003 00000000 00008e70 00000000 b6f17000 00000036 dfa0: c000e484 c000e300 00008e70 00000000 00000003 c0246f00 bec33d18 bec33d18 dfc0: 00008e70 00000000 b6f17000 00000036 00000000 00000000 b6f6d000 bec33d4c dfe0: b6ea1bd0 bec33d0c 00008c9c b6ea1bdc 60000010 00000003 00000000 00000000 (_omap_device_enable_hwmods+0x20/0x34) (omap_device_enable+0x3c/0x50) (_od_runtime_resume+0x10/0x1c) (__rpm_callback+0x54/0x98) (rpm_callback+0x64/0x7c) (rpm_resume+0x434/0x554) (__pm_runtime_resume+0x48/0x74) (omap_i2c_xfer+0x28/0xe8) (__i2c_transfer+0x3c/0x78) (i2c_transfer+0x6c/0xc0) (i2c_master_send+0x38/0x48) (sha204p_send_command+0x60/0x9c) (sha204c_send_and_receive+0x5c/0x1e0) (sha204m_read+0x94/0xa0) (otp_do_read+0x50/0xa4) (vfs_ioctl+0x24/0x40) (do_vfs_ioctl+0x1b0/0x1c0) (sys_ioctl+0x38/0x54) (ret_fast_syscall+0x0/0x30) Code: e1a08002 ea000009 e598003c e592c05c (e7904003) Cc: stable@vger.kernel.org Signed-off-by: Jean-Philippe Fran=C3=A7ois <jp.francois@cynove.com> Acked-by: Kevin Hilman <khilman@linaro.org> [tony@atomide.com: updated description with oops] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
c48cd659892962f79bba4b4e0eedea8e5aa54c44 |
|
13-Mar-2013 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: OMAP: use consistent error checking Consistently check errors using the usual method used in the kernel for much of its history. For instance: int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t) { int div; div = gpmc_calc_divider(t->sync_clk); if (div < 0) return div; static int gpmc_set_async_mode(int cs, struct gpmc_timings *t) { ... return gpmc_cs_set_timings(cs, t); ..... ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t); if (IS_ERR_VALUE(ret)) return ret; So, gpmc_cs_set_timings() thinks any negative return value is an error, but where we check that in higher levels, only a limited range are errors... There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really appropriate, and that is in arch/arm/include/asm/syscall.h: static inline long syscall_get_error(struct task_struct *task, struct pt_regs *regs) { unsigned long error = regs->ARM_r0; return IS_ERR_VALUE(error) ? error : 0; } because this function really does have to differentiate between error return values and addresses which look like negative numbers (eg, from mmap()). So, here's a patch to remove them from OMAP, except for the above. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
97597b962529fef9c6976bab57f25ef5ce5e7383 |
|
19-Mar-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc OMAP hwmod layer does the reset of the IPs in early code so that we have SOC in sane state. To do the soft-reset, it needs to ioremap() the IP address space to be able to write to sysconfig registers. But there are few hwmod which doesn't have sysconfig registers and hence no need to ioremap() them in early init code. Prevent calling the _init_mpu_rt_base() conditional based on sysc availability. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
|
079abade857e7ba7877a84536fbf5da5fa665d70 |
|
21-Jan-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: OMAP2+: hwmod: extract module address space from DT blob Patch adds the code for extracting the module ocp address space from device tree blob in case the hwmod address space look up fails. The idea is to remove the address space data from hwmod and extract it from DT blob. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Benoit Cousson <benoit.cousson@linaro.org>
|
f7b861b7a6d9d1838cbbb5f4053e61578b86d134 |
|
21-Mar-2013 |
Thomas Gleixner <tglx@linutronix.de> |
arm: Use generic idle loop Use the generic idle loop and replace enable/disable_hlt with the respective core functions. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Reviewed-by: Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Russell King <linux@arm.linux.org.uk> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP Link: http://lkml.kernel.org/r/20130321215233.826238797@linutronix.de
|
4280943b6bc81357eb61c3e1111d2d83ec2ef03d |
|
01-Apr-2013 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag _HWMOD_WAKEUP_ENABLED is currently unused across the hwmod framework. Just get rid of it, so we have one less flag to worry about. Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
71856843fb1d8ee455a4c1a60696c74afa4809e5 |
|
13-Mar-2013 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: OMAP: use consistent error checking Consistently check errors using the usual method used in the kernel for much of its history. For instance: int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t) { int div; div = gpmc_calc_divider(t->sync_clk); if (div < 0) return div; static int gpmc_set_async_mode(int cs, struct gpmc_timings *t) { ... return gpmc_cs_set_timings(cs, t); ..... ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t); if (IS_ERR_VALUE(ret)) return ret; So, gpmc_cs_set_timings() thinks any negative return value is an error, but where we check that in higher levels, only a limited range are errors... There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really appropriate, and that is in arch/arm/include/asm/syscall.h: static inline long syscall_get_error(struct task_struct *task, struct pt_regs *regs) { unsigned long error = regs->ARM_r0; return IS_ERR_VALUE(error) ? error : 0; } because this function really does have to differentiate between error return values and addresses which look like negative numbers (eg, from mmap()). So, here's a patch to remove them from OMAP, except for the above. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
092bc089c249de0fa0f0c98b28dea6e5f1367b6e |
|
11-Mar-2013 |
Grazvydas Ignotas <notasas@gmail.com> |
ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb For some unknown reason, allowing hwmod to control MIDLEMODE causes core_pwrdm to not hit idle states for musb in DM3730 at least. I've verified that setting any MIDLEMODE value other than "force standby" before enabling the device causes subsequent suspend attempts to fail with core_pwrdm not entering idle states, even if the driver is unloaded and "force standby" is restored before suspend attempt. To recover from this, soft reset can be used, but that's not suitable solution for suspend. Keeping the register set at force standby (reset value) makes it work and device still functions properly, as musb has driver-controlled OTG_FORCESTDBY register that controls MSTANDBY signal. Note that TI PSP kernels also have similar workarounds. This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the actual flag name. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6d266f63a11bce427504d203834df3c0bb9be9a5 |
|
10-Feb-2013 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add enable_preprogram hook After setup/enable, some IP blocks need some additional setting to indicate the PRCM that they are inactive until they are configured. Some examples on OMAP4 include the AESS and FSUSB IP blocks. To fix this cleanly, this patch adds another optional function pointer, enable_preprogram, to the IP block's hwmod data. The function that is pointed to is called by the hwmod code immediately after the IP block is reset. This version of the patch includes a patch description fix from Felipe. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Péter Ujfalusi <peter.ujfalusi@ti.com> Cc: Felipe Balbi <balbi@ti.com>
|
3c06f1b8c3ca74669b77c0aaee428b5c46d3e552 |
|
29-Jan-2013 |
Vaibhav Bedia <vaibhav.bedia@ti.com> |
ARM: OMAP2+: AM33XX: Update the hardreset API WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST) Update the hardreset API to ensure that the reset line properly deasserted. Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
db27c0c0d05cafc0eb0bed4d58daea65ed5e6839 |
|
30-Dec-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while certain peripherals are active. It's not clear why, and it's likely that there is simply some other bug in the driver or integration code. But since the likelihood that anyone will have the time to track these problems down in the future seems quite small, we'll provide a flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
fa2002223e12c6b1bc96381b70c376afe4e01d80 |
|
26-Jan-2013 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while certain peripherals are active. It's not clear why, and it's likely that there is simply some other bug in the driver or integration code. But since the likelihood that anyone will have the time to track these problems down in the future seems quite small, we'll provide a flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b76c8b19b082c3fc84725de0d3ba5ee1f571c0ae |
|
11-Jan-2013 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Use omap initcalls This way the initcalls don't run on other SoCs on multiplatform kernels. Otherwise we'll get something like this when booting on vexpress: omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered ... WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94() _init_omap_device: could not find omap_hwmod for mpu ... omap-dma-engine omap-dma-engine: OMAP DMA engine driver ... Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
dad4191d79bded6674529084bcf842c00e4d874a |
|
22-Nov-2012 |
Peter Ujfalusi <peter.ujfalusi@ti.com> |
ARM: OMAP2+: hwmod: Add possibility to count hwmod resources based on type Add flags parameter for omap_hwmod_count_resources() so users can tell which type of resources they are interested when counting them in hwmod database. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
e6d3a8b0bdcd8f323488a52927682190aee5488e |
|
22-Nov-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count OMAP4 has module specific context lost registers which makes it now possible to have module level context loss count, instead of relying on the powerdomain level context count. Add 2 private hwmod api's to update/clear the hwmod/module specific context lost counters/register. Update the module specific context_lost_counter and clear the hardware bits just after enabling the module. omap_hwmod_get_context_loss_count() now returns the hwmod context loss count them on platforms where they exist (OMAP4), else fall back on the pwrdm level counters for older platforms. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: added function kerneldoc, fixed structure kerneldoc, rearranged structure to avoid memory waste, marked fns as OMAP4-specific, prevent fn entry on non-OMAP4 chips, reduced indentation, merged update and clear, merged patches] [t-kristo@ti.com: added support for arch specific hwmod ops, and changed the no context offset indicator to USHRT_MAX] Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX; convert unsigned context lost counter to int to match the return type; get rid of hwmod_ops in favor of the existing soc_ops mechanism; move context loss low-level accesses to the PRM code] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
c4a1ea2c6229b18c10c5a49a0f8f4ad2c3e2355d |
|
27-Apr-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP: hwmod: Cleanup !CONFIG_COMMON_CLK parts Clean all #ifdef's added as part of fixing the clkdm accesses from hwmod. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Mike Turquette <mturquette@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b797be1d4c079e78a3cb4e95f4a74274a4aef9f5 |
|
09-Jul-2012 |
Vaibhav Hiremath <hvaibhav@ti.com> |
ARM: OMAP2+: hwmod: Invoke init_clkdm before other init functions Without this kernel would crash, since clkdm inside omap_hwmod is accessed in some of the init functions like, _init_main_clk. So call init_clkdm before _init_main_clk(). Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Mike Turquette <mturquette@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
f5dd3bb53ca45f3b47c6889e5920c562f5a37359 |
|
11-Nov-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP: hwmod: Fix up hwmod based clkdm accesses hwmod uses deferencing the clk pointer to acccess the clkdm. With COMMON clk hwoever this will need to be deferenced through the clk_hw_omap pointer, so do the necessary changes. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Mike Turquette <mturquette@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b99db36cdf37decb1b5575c5f293d170cbbc53d6 |
|
30-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h are now completely unused and can be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
|
2577a4a6096017f3152339c562ada77e182c8976 |
|
30-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call The hwmod code unconditionally calls _omap4_disable_module() on all SoCs when a module doesn't enable correctly. This "worked" due to the weak function omap4_cminst_wait_module_idle() in arch/arm/mach-omap2/prcm.c, which was a no-op. But now those weak functions are going away - they should not be used. So this patch will now call the SoC-specific disable_module code, assuming it exists. Needs to be done before the weak function is removed, otherwise AM33xx will crash early in boot. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
|
b13159afb46f8a528fcf30bac26c07dbb40a784a |
|
30-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros Consolidate all of the copies of MAX_MODULE_HARDRESET_WAIT and MAX_MODULE_SOFTRESET_WAIT into one place, arch/arm/mach-omap2/prm.h. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
|
5fb3d522efca4b3a369040d37d1380103411db74 |
|
30-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is dependent on an off-chip functional clock that is not guaranteed to be present during initialization. IP blocks marked with this flag are left in the INITIALIZED state during kernel init. This is a workaround for a hardware problem. It should be possible to guarantee that at least one clock source will be present and active for any IP block's main functional clock. This ensures that the hwmod code can enable and reset the IP block. Resetting the IP block during kernel init prevents any bogus bootloader, ROM code, or previous OS configuration from affecting the kernel. Hopefully a clock multiplexer can be added on future SoCs. N.B., at some point in the future, it should be possible to query the clock framework for this type of information. Then this flag should no longer be needed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
613ad0e98c3596cd2524172fae2a795c3fc57e4a |
|
30-Oct-2012 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod When waking up from off-mode, some IP blocks are reset automatically by hardware. For this reason, software must wait until the reset has completed before attempting to access the IP block. This patch fixes for example the bug introduced by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c ("mmc: omap_hsmmc: remove access to SYSCONFIG register"), in which the MMC IP block is reset during off-mode entry, but the code expects the module to be already available during the execution of context restore. This version includes a fix from Kevin Hilman <khilman@ti.com> for GPIO problems on the 37xx EVM - thanks Kevin. Signed-off-by: Tero Kristo <t-kristo@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Venkatraman S <svenkatr@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Cc: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: moved softreset wait code into separate function; call from top of _enable_sysc() rather than the bottom; include fix from Kevin Hilman for GPIO sluggishness] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
ff4ae5d9319b86f940e410e92659c50f9879ff46 |
|
21-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: CM/hwmod: split CM functions into OMAP2, OMAP3-specific files Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and OMAP2xxx-specific macros into cm2xxx.[ch]. Move basic CM register access functions into static inline functions in cm2xxx_3xxx.h, leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c. As part of this, split the CM and hwmod code that waits for devices to become ready into SoC-specific functions. This is in preparation for the upcoming move of this code to drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com> Reviewed-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
139563ad27e7baad7935b8113940f0d804cf513b |
|
21-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: PRM: split PRM functions into OMAP2, OMAP3-specific files Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and OMAP2xxx-specific macros into prm2xxx.h. (prm2xxx.c will be created by a subsequent patch when it's needed.) Move basic PRM register access functions into static inline functions in prm2xxx_3xxx.h, leaving only OMAP2/3 hardreset functions in prm2xxx_3xxx.c. Also clarify the initcall function naming to reinforce that this code is specifically for the PRM IP block. This is in preparation for the upcoming powerdomain series and the upcoming move of this code to drivers/. Signed-off-by: Paul Walmsley <paul@pwsan.com> Reviewed-by: Russ Dill <Russ.Dill@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
a135eaae524acba1509a3b19c97fae556e4da7cd |
|
27-Sep-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP: remove plat/clock.h Remove arch/arm/plat-omap/include/plat/clock.h by merging it into arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h. The goal here is to facilitate ARM single image kernels by removing includes via the "plat/" symlink. Signed-off-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: fixed to remove duplicate clock.h includes] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
2a296c8f89bc6aaf91b255c7d631fcbbfaf840ec |
|
03-Oct-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Make plat/omap_hwmod.h local to mach-omap2 Let's make omap_hwmod local to mach-omap2 for ARM common zImage support. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
e9332b6eed82973a8f75f1f3d57babaa331d703c |
|
09-Oct-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling Commit eb05f691290e99ee0bd1672317d6add789523c1e ("ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled") added code to skip the IP block disable sequence if all of the block's hardreset lines weren't asserted. But this did not handle the case when no hardreset lines were associated with a module, which is the general case. In that situation, the IP block disable would be skipped. This is likely to cause PM regressions. So, modify _omap4_disable_module() and _am33xx_disable_module() to only bail out early if there are any hardreset lines asserted. And move the AM33xx test above the actual module disable code to ensure that the behavior is consistent. Reported-by: Archit Taneja <a0393947@ti.com> Tested-by: Archit Taneja <a0393947@ti.com> # DSS Cc: Omar Ramirez Luna <omar.luna@linaro.org> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> # AM335x Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b71c72178e24118214f21567a15adcad61b4238a |
|
24-Sep-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems The idle status of the IP blocks and clocks inside the EMU clockdomain isn't taken into account by the PRCM hardware when deciding whether the clockdomain is idle. Add a workaround flag in the clockdomain code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add the code necessary to support it. If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the clockdomain will be forced active whenever an IP block inside that clockdomain is in use, even if the clockdomain supports hardware-supervised idle. When the kernel indicates that the last active IP block inside the clockdomain is no longer used, the clockdomain will be forced idle, or, if that mode is not supported in the hardware, it will be placed into hardware-supervised idle. This patch is an equal collaboration with Jon Hunter <jon-hunter@ti.com>. Ming Lei <ming.lei@canonical.com>, Will Deacon <will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman <khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh Shilimkar <santosh.shilimkar@ti.com> all made essential contributions to the understanding of EMU clockdomain power management on OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Madhav Vij <mvij@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Jon Hunter <jon-hunter@ti.com>
|
e8e96dff71efcf880d9fa446651b3c3db08957c4 |
|
24-Sep-2012 |
Omar Ramirez Luna <omar.luna@linaro.org> |
ARM: OMAP: hwmod: revise deassert sequence For a reset sequence to complete cleanly, a module needs its associated clocks to be enabled, otherwise the timeout check in prcm code can print a false failure (failed to hardreset) that occurs because the clocks aren't powered ON and the status bit checked can't transition without them. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
eb05f691290e99ee0bd1672317d6add789523c1e |
|
24-Sep-2012 |
Omar Ramirez Luna <omar.luna@linaro.org> |
ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled Some IP blocks might not be using/controlling more than one reset line, this check loosens the restriction to fully use hwmod framework for those drivers. E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. - As of now cpu1 is not used and hence (with previous check) the IP block isn't fully enabled by hwmod code. - Usually ipu and dsp processors configure their mmu module first and then enable the processors, this involves: * Deasserting mmu reset line, and enabling the module. * Deasserting cpu0 reset line, and enabling the processor. The ones portrayed in this example are controlled through rproc_fw_boot in drivers/remoteproc/remoteproc_core.c While at it, prevent _omap4_module_disable if all the hardreset lines on an IP block are not under reset. This will allow the driver to: a. Deassert the reset line. b. Enable the hwmod through runtime PM default callbacks. c. Do its usecase. d. Disable hwmod through runtime PM. e. Assert the reset line. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
3bb05dbf69018177c06ee09011e2d8bd183dd2ba |
|
24-Sep-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages The decision was made a few months ago to allow struct omap_hwmod records and struct clk records to omit clockdomain information if the clockdomain is not software-controllable. See for example commit 868c157df9721675c19729eed2c96bac6c3f1d01 ("ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain"). So convert an existing pr_warning() to a pr_debug() (regarding missing clockdomains in clocks), and add a pr_debug() for missing hwmod clockdomains. It's still useful to enable these messages for debugging, since missing clockdomains can cause hard-to-debug problems with power management; see for example commit 6c4a057bffe9823221eab547e11fac181dc18a2b ("ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock"). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
2b026d137b13047d01d426a61e2d50b5dcb58fd0 |
|
24-Sep-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*() We're no longer requiring struct omap_hwmod records to contain a clockdomain. So we shouldn't return -EINVAL any more from _omap4_wait_target_disable() or _omap4_wait_target_ready() if there's no clockdomain defined, since that just gets passed back to the caller. This can result in pointless warnings under the relaxed data format. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
5dcc3b975e972989574c009457f0e333c342910d |
|
22-Sep-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk While we move to Common Clk Framework (CCF), direct deferencing of struct clk wouldn't be possible anymore. Hence get rid of all such instances in the current clock code and use macros/helpers similar to the ones that are provided by CCF. While here also concatenate some strings split across multiple lines which seem to be needed anyway. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: simplified some compound expressions; reformatted some messages] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Mike Turquette <mturquette@linaro.org>
|
6ea74cb9853e923f8945586cd9ccdd42e6f00ba9 |
|
22-Sep-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage Moving to Common clk framework for OMAP would mean we no longer use internal lookup mechanism like omap_clk_get_by_name(). get rid of all its usage mostly from hwmod and omap_device code. Moving to clk_get() also means the respective platforms need the clkdev tables updated with an entry for all clocks used by hwmod to have clock name same as the alias. Based on original changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> [paul@pwsan.com: removed IS_ERR_OR_NULL() conversion (rmk comment); restricted omap_96m_alwon_fck_3630 to OMAP36xx; added missing AM35xx clock aliases for emac_fck, emac_ick, vpfe_ick, vpfe_fck; added aliases rng_ick and several emulation clocks] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
4d7cb45ee823541632a3d50f57031ce9fd60e13f |
|
22-Sep-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: omap: clk: add clk_prepare and clk_unprepare As part of Common Clk Framework (CCF) the clk_enable() operation was split into a clk_prepare() which could sleep, and a clk_enable() which should never sleep. Similarly the clk_disable() was split into clk_disable() and clk_unprepare(). This was needed to handle complex cases where in a clk gate/ungate would require a slow and a fast part to be implemented. None of the clocks below seem to be in the 'complex' clocks category and are just simple clocks which are enabled/disabled through simple register writes. Most of the instances also seem to be called in non-atomic context which means its safe to move all of those from using a clk_enable() to clk_prepare_enable() and clk_disable() to clk_disable_unprepare(). For some others, mainly the ones handled through the hwmod framework there is a possibility that they get called in either an atomic or a non-atomic context. The way these get handled below work only as long as clk_prepare is implemented as a no-op (which is the case today) since this gets called very early at boot while most subsystems are unavailable. Hence these are marked with a *HACK* comment, which says we need to re-visit these once we start doing something meaningful with clk_prepare/clk_unprepare like doing voltage scaling or something that involves i2c. This is in preparation of OMAP moving to CCF. Based on initial changes from Mike Turquette. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
dbc04161048dd5e5c3c58546688a0cc0854051e9 |
|
31-Aug-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP: Split plat/hardware.h, use local soc.h for omap2+ As the plat and mach includes need to disappear for single zImage work, we need to remove plat/hardware.h. Do this by splitting plat/hardware.h into omap1 and omap2+ specific files. The old plat/hardware.h already has omap1 only defines, so it gets moved to mach/hardware.h for omap1. For omap2+, we use the local soc.h that for now just includes the related SoC headers to keep this patch more readable. Note that the local soc.h still includes plat/cpu.h that can be dealt with in later patches. Let's also include plat/serial.h from common.h for all the board-*.c files. This allows making the include files local later on without patching these files again. Note that only minimal changes are done in this patch for the drivers/watchdog/omap_wdt.c driver to keep things compiling. Further patches are needed to eventually remove cpu_is_omap usage in the drivers. Also only minimal changes are done to sound/soc/omap/* to remove the unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's no need to include omap44xx.h. While at it, also sort some of the includes in the standard way. Cc: linux-watchdog@vger.kernel.org Cc: alsa-devel@alsa-project.org Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com> Cc: Liam Girdwood <lrg@ti.com> Acked-by: Wim Van Sebroeck <wim@iguana.be> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
7852ec0536ca39cefffc6301dc77f8ae55592926 |
|
26-Jul-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP: unwrap strings Find and unwrap wrapped strings in the style: pr_debug("clockdomain: hardware cannot set/clear wake up of " "%s when %s wakes up\n", clkdm1->name, clkdm2->name); Keeping these strings contiguous seems to be the current Linux kernel policy. The offending lines were found with the following command: pcregrep -rnM '"\s*$\s*"' arch/arm/*omap* While here, some messages have been clarified, some pr_warning( ... calls have been converted to pr_warn( ..., and some printk(KERN_* ... have been converted to pr_*. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
a032d33b65c89a781c871fd1def595fa6a69b52a |
|
03-Aug-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP: clean up some smatch warnings, fix some printk(KERN_ERR ... Resolve the following warnings from smatch: arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1? arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR() arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1 arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata' arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret' arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same. arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627) arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13 arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'. arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1 Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG() can be disabled. The changes in the first version that removed the subsequent return() after BUG() states have been dropped. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
|
1688bf19b8daaa2eb4e861c33a6396ca85b890c3 |
|
12-Sep-2012 |
Vaibhav Hiremath <hvaibhav@ti.com> |
ARM: OMAP2+: hwmod: Hook-up am33xx support in omap_hwmod framework AM33XX PRCM architecture is different that any OMAP family of devices, so it is required to have separate implementation to handle AM33XX module enable/disable, reset assert/deassert functionality. This patch adds wrapper api's in omap_hwmod framework to access prm/cm for AM33XX family of devices. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com> [paul@pwsan.com: fixed checkpatch messages] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b82b04e8eb27abe0cfe9cd7bf4fee8bb1bb9b013 |
|
29-Aug-2012 |
Vaibhav Hiremath <hvaibhav@ti.com> |
ARM: OMAP: omap_device: Do not overwrite resources allocated by OF layer With the new devices (like, AM33XX and OMAP5) we now only support DT boot mode of operation and now it is the time to start killing slowly the dependency on hwmod, so with this patch, we are starting with device resources. The idea here is implemented considering to both boot modes - - DT boot mode OF framework will construct the resource structure (currently does for MEM & IRQ resource) and we should respect/use these resources, killing hwmod dependency. If pdev->num_resources > 0, we assume that MEM & IRQ resources have been allocated by OF layer already (through DTB). Once DMA resource is available from OF layer, we should kill filling any resources from hwmod. - Non-DT boot mode Here, pdev->num_resources = 0, and we should get all the resources from hwmod (following existing steps) Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> [b-cousson@ti.com: Fix some checkpatch CHECK issues] Signed-off-by: Benoit Cousson <b-cousson@ti.com>
|
471a009b6db7670299a8674cd7fb2557c8c2797f |
|
03-Sep-2012 |
Misael Lopez Cruz <misael.lopez@ti.com> |
ARM: OMAP: hwmod code: Disable module when hwmod enable fails Clock and module mode are explictly enable when hwmod is enabled. But if the hwmod doesn't get ready on time, clocks are disabled but module is left enabled. Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
05e152c76a1efaa3165afecf5acf535c8283f386 |
|
05-Jun-2012 |
R Sricharan <r.sricharan@ti.com> |
ARM: OMAP5: Add minimal support for OMAP5430 SOC OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and with an integrated L2 cache controller. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Patch includes: - The machine specific headers and sources updates. - Platform header updates. - Minimum initialisation support for serial. - IO table init Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
68c9a95e9253ce1776bd21bf8d37ddf213cced66 |
|
06-Jul-2012 |
Tony Lindgren <tony@atomide.com> |
ARM: OMAP2+: Fix mismerge for omap_hwmod_get_main_clk() API Commit ac5b0ea3d (Merge tag 'omap-devel-f-for-3.6'...) had a merge conflict that somehow got incorrecly resolved in a lossy way for commit bed9d1bb (ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API). Fix the issue by applying the missing pieces. Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
006c7f18449a06027b0165e938c67b3a029813c9 |
|
04-Jul-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c ("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database") broke CORE idle on OMAP3. This prevents device low power states. The root cause is that the 32K sync timer IP block does not support smart-idle mode[1], and so the hwmod code keeps the IP block in no-idle mode while it is active. This in turn prevents the WKUP clockdomain from transitioning to idle. There is a hardcoded sleep dependency that prevents the CORE_L3 and CORE_CM clockdomains from transitioning to idle when the WKUP clockdomain is active[2], so the chip cannot enter any device low power states. It turns out that there is no need to take the 32k sync timer out of idle. The IP block itself probably does not have any native idle handling at all, due to its simplicity. Furthermore, the PRCM will never request target idle for this IP block while the kernel is running, due to the sleep dependency that prevents the WKUP clockdomain from idling while the CORE_L3 clockdomain is active. So we can safely leave the 32k sync timer in target-force-idle mode, even while we continue to access it. This workaround is implemented by defining a new clockdomain flag, CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is guaranteed to be active whenever the MPU is inactive. If an IP block's main functional clock exists inside this clockdomain, and the IP block does not support smart-idle modes, then the hwmod code will place the IP block into target force-idle mode even when enabled. The WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx, no OCP header existed on the 32k sync timer.) Other clockdomains also should be marked with this flag, but those changes are deferred until a later merge window, to create a minimal fix. Another theoretically clean fix for this problem would be to implement PM runtime-based control for 32k sync timer accesses. These PM runtime calls would need to located in a custom clocksource, since the 32k sync timer is currently used as an MMIO clocksource. But in practice, there would be little benefit to doing so; and there would be some cost, due to the addition of unnecessary lines of code and the additional CPU overhead of the PM runtime and hwmod code - unnecessary in this case. Another possible fix would have been to modify the pm34xx.c code to force the IP block idle before entering WFI. But this would not have been an acceptable approach: we are trying to remove this type of centralized IP block idle control from the PM code. This patch is a collaboration between Kevin Hilman <khilman@ti.com> and Paul Walmsley <paul@pwsan.com>. Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on an earlier version of this patch. Thanks to Tero Kristo <t-kristo@ti.com> for identifying a bug in an earlier version of this patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying some bugs in several versions of this patch and for implementation comments. References: 1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU (SWPU223U), available from: http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip 2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU (SWPU223U) 3. ibid. Cc: Tony Lindgren <tony@atomide.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tero Kristo <t-kristo@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
|
6668546f3bb4cc0dde75ac1ef1d436b67e4ef638 |
|
04-Jul-2012 |
Kishon Vijay Abraham I <kishon@ti.com> |
ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework The DMADISABLE bit is a semi-automatic bit present in sysconfig register of some modules. When the DMA must perform read/write accesses, the DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power management, software must set the DMADISABLE bit back to 1. In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the DMADISABLE bit (but the romcode/bootloader might not set it back to 1). In order for the kernel to start in a clean state, it is necessary for the kernel to set DMADISABLE bit back to 1 (irrespective of whether it's been set to 1 in romcode or bootloader). During _reset of the (hwmod)device, the DMADISABLE bit is set so that it does not prevent idling of the system. (NOTE: having DMADISABLE to 0, prevents the system to idle) DMADISABLE bit is present in usbotgss module of omap5. Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> [paul@pwsan.com: updated to apply; fixed checkpatch warnings] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
bed9d1bb4ed8c9bdaca77d31a2562c3a9dae43a7 |
|
04-Jul-2012 |
Tarun Kanti DebBarma <tarun.kanti@ti.com> |
ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API Add an API to get main clock name associated with a given @oh. This will avoid the need to construct fclk names during early initialization in order to get fclk handle using clk_get(). Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
5165882a387325ac0df2f30c62ea710cfa328b54 |
|
22-Jun-2012 |
Vishwanath BS <vishwanath.bs@ti.com> |
ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during hwmod mux IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP). Now devices can idle independent of the powerdomain, there can be a window where device is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations, since both module wake up is enabled at padlevel as well as io daisychain sequence is triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the first interrupt, module specific interrupt handler will not triggered for the second time Also look at detailed explanation given by Rajendra at http://www.spinics.net/lists/linux-serial/msg04480.html Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: remove dependency on pm.c & pm.h; add kerneldoc] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
561038f0a8aa1de272a2ac5dad24cc8246d9f496 |
|
17-Jun-2012 |
Djamil Elaidi <d-elaidi@ti.com> |
ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup. Signed-off-by: Djamil Elaidi <d-elaidi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
868c157df9721675c19729eed2c96bac6c3f1d01 |
|
19-Jun-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
0a179eaa436e58ed9fd00e09cdf01f1b3604d9a1 |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm Rather than use runtime cpu_is* checking inside _init_clkdm, initialize SoC specific function pointer at init time. Signed-off-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: convert to use soc_ops function pointers; remove second para from commit message since soc_ops function pointers are now set during hwmod layer init] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
b8249cf2d2b16de9582d3cbaa98c16c32c624d8a |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP2+: hwmod: use init-time function pointer for hardreset Rather than using cpu_is* checking at runtime, initialize SoC specific function pointers for the various hard reset functions at init time. Signed-off-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
8f6aa8ee114fb52a425e247e27e271ee35d7d3b3 |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready Rather than using cpu_is* checking at runtime, initialize an SoC specific function pointer for wait_target_ready(). While here, downgrade the BUG() to a WARN_ON() so it gives a noisy warning instead of causing a kernel panic. Signed-off-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc; move soc_ops functions to their own section in the code; integrated the _wait_target_ready() function with the OMAP2/OMAP4 variants; renamed the wait_module_ready field to wait_target_ready] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
baa2607f56f1589eb21c01fe16aa5f5c3f9dad31 |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable() _omap4_wait_target_disable() is called only from inside _omap4_disable_module() which is already protected by SoC specific checks. Remove the cpu_is check here. Signed-off-by: Kevin Hilman <khilman@ti.com>
|
9ebfd285371835b1c0243d15aaacd72d5def76f8 |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module The enable/disable module functions are specific to SoCs with OMAP4-class PRCM. Rather than use cpu_is* checks at runtime inside the enable/disable module functions, use cpu_is at init time to initialize function pointers only for SoCs that need them. NOTE: the cpu_is* check for _enable_module was different than the one for _disable_module, and this patch uses cpu_is_omap44xx() for both. Signed-off-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than per-hwmod since they do not vary by hwmod; added kerneldoc] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
3d9f032724e72851c6de38d026b2417501a2f240 |
|
18-Jun-2012 |
Kevin Hilman <khilman@ti.com> |
ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module() _enable_module is specific to SoCs with PRCM interfaces similar to that of the OMAP4, so rename it to be consistent with the corresponding _omap4_disable_module. Signed-off-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: tweaked commit message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
11cd4b94cb491894b8a192635abf159fc1917f4d |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP: hwmod: remove code support for direct hwmod registration Now that the data has been converted to use interface registration, we can remove the (now unused) direct hwmod registration code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
2221b5cddc2ebcfa4b0217266d2edc98e7eec93b |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add support for link registration Add support for direct IP block interconnect ("link") registration to the hwmod code via a new function, omap_hwmod_register_links(). This will replace direct registration of hwmods, and a subsequent patch will remove omap_hwmod_register(). This change will allow a subsequent patch to remove the hwmod data link arrays. This will reduce the size of the hwmod static data and also make it easier to generate the data files. It will also make it possible to share some of the struct omap_hwmod records across multiple SoCs, since the link array pointers will be removed from the struct omap_hwmod. The downside is that boot time will increase. Minimizing boot time was the reason why the link arrays were originally introduced. Removing them will require extra computation during boot to allocate memory and associate IP blocks with their interconnects. However, since the current kernel development focus is on reducing the number of lines in arch/arm/mach-omap2/, boot time impact is now seemingly considered a lower priority. This patch contains additional complexity to reduce the number of memory allocations required for this change. This reduces the boot time impact: total hwmod link registration time was ~ 2655 microseconds with a simple allocation strategy, but is now ~ 549 microseconds[1] with the approach taken by this patch. 1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average of 7 samples. Total uncertainty is +/- 61 microseconds. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
24dbc2130179ebd493a241f6f5972cf6524b933a |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it An IP block's MPU interface port only needs to be found once. The result can be cached to speed further lookups. This patch consolidates these two steps into a single function. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
5d95dde7316101656102cb585b73381e4eaadaa7 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if To reduce the number of lines of data in the OMAP portion of the Linux code base, subsequent patches will remove the lists of hwmod interconnect links from the static hwmod data. These lists will be built dynamically during boot. To ease this transition, this patch centralizes the way that interconnect links are iterated into a single function, _fetch_next_ocp_if(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
2d6141baf15df188283ada7c0fa04679c4fcf1c7 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add _find_mpu_rt_port() Most IP blocks on the OMAP SoC have an interconnect link that is intended to be used by the MPU to communicate with the IP block. Several parts of the hwmod code need to be able to identify this link. Currently, this is open-coded. However, future patches will change the way that interconnect links are represented and will make identifying the link more complex. So to avoid code duplication, this patch centralizes the MPU port link identification code into a new function, _find_mpu_rt_port(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
5e8370f1fa01bf232ca4770c6d81bbf42437d2a3 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname() The timer integration code pokes around in hwmod data structures. Those data structures are about to change. Define a function, omap_hwmod_get_resource_byname(), for the timer integration code to use instead. The original patch has been changed to use struct resource by Tony's request, although the caller of this function should not be a driver._ Platform drivers should get their data through the regular platform_* functions; DT drivers through the appropriate of_* functions. This a function is only for use by OMAP core code in arch/arm/*omap*. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
|
c9aafd23d6c1b466f37f554e9916886e7d4645d0 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RT A subsequent patch will need to know the struct omap_hwmod_addr_space record corresponding to the module's register target, used by the MPU. So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space(). Then modify its sole current user, _populate_mpu_rt_base(), to extract the MPU RT base address itself from the struct omap_hwmod_addr_space record. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
747834ab83475f47878c68954d913e27124e4391 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: revise hardreset behavior Change the way that hardreset lines are handled by the hwmod code. Hardreset lines are generally associated with initiator IP blocks. Prior to this change, the hwmod code expected to control hardreset lines itself, asserting them on shutdown and deasserting them upon enable. But driver authors inside TI have commented to us that their drivers require direct control over these lines. Unfortunately, these drivers haven't been posted publicly yet, so it's hard to determine exactly what is needed, a priori. This change attempts to set forth some reasonable semantics that should be an improvement over the current code. The semantics implemented by this patch are as follows: - If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all associated hardreset lines during IP block setup. This is intended to place the IP blocks into a known state that will not interfere with other devices during kernel boot. - IP blocks with hardreset lines will not be automatically enabled or idled during setup. Instead, they will be left in the INITIALIZED state. - When the hwmod code is asked to enable, idle, or shutdown an IP block with asserted hardreset lines, the hwmod code will do nothing. The driver integration code must do the remaining work needed to control these IP blocks. Once this driver integration code is posted to the lists, hopefully we can consolidate it and move it inside the hwmod code. Custom reset functions for IP blocks with hardreset lines still should be supported and are strongly endorsed. It is intended that every subsystem with hardreset lines should have a custom reset function that can place their subsystem into quiescent idle with the hardreset lines deasserted. This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42 ("OMAP: hwmod: Add hardreset management support"). Later code reorganizations caused the sequencing of the code from this patch to be changed, anyway. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
64813c3fa68fc3e93e99187d313126710d7c4b0d |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: reorganize and document the reset and configuration process Reorganize the code involved in resetting and configuring an IP block to make it easier to read and maintain. This involves improving documentation, splitting some large functions up into smaller ones to better conform with Documentation/CodingStyle, and removing some unnecessary code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
381d033a0164afaaac2a1c35bc8bc379052595b2 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: reorganize and document the initialization process Reorganize the code involved in initializing the internal data for each hwmod to make it easier to read and maintain. This involves improving documentation and removing some duplicated and unnecessary code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
30e105c000abbac55602b37f4831437bca5487b0 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: revise the IP block reset process Revise the IP block reset process. This patch ensures that the OCP_SYSCONFIG registers are reloaded after a custom reset. Since OCP_SYSCONFIG bits are cleared during reset, they should be reprogrammed unless the IP block is being left in reset. (The only IP blocks that are left in reset are IP blocks with hardreset lines and no custom reset function.) If the IP block is left in reset, then it is inaccessible to the MPU, and an access to the OCP_SYSCONFIG register will cause an abort. This version incorporates comments from Omar Ramirez Luna <omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting hardreset lines. This allows the MMU (IOMMU) IP block, which has both hardreset lines and an OCP_SYSCONFIG register. Also, ignore _ocp_softreset() errors if the IP block doesn't include a softreset bit. This is needed since a subsequent patch will start taking the return value of the _reset() function seriously. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
|
9c8b0ec7a46c5840fddaa570933335f4ccbbd078 |
|
19-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmod Parts of the hwmod code test to see if a module has one and only one hardreset line before taking an action. It seems more appropriate to control all hardreset lines associated with a hwmod, not just one. It so happens that with the current hwmod data, this patch will not change any behavior, since hwmods with hardreset lines have only one hardreset line associated with them, and 'pseudo-hwmods' are used to handle the other hardreset lines. But future hwmod data patches to remove the pseudo-hwmods will change this. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
3c55c1baffa5f719eb2ae9729088bc867f972f53 |
|
13-Apr-2012 |
Paul Walmsley <paul@pwsan.com> |
ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status" This reverts commit f9a2f9c3fa76eec55928e8e06f3094c8f01df7cb. This commit caused a regression in the I2C hwmod reset on OMAP2/3/4, logging messages similar to these during boot: [ 0.200378] omap_hwmod: i2c1: softreset failed (waited 10000 usec) [ 0.222076] omap_hwmod: i2c2: softreset failed (waited 10000 usec) While the original patch was intended to fix some reset-related timing issues, it's believed that these problems were actually fixed by commit 2800852a079504f35f88e44faf5c9c96318c0cca ("ARM: OMAP2+: hwmod: Restore sysc after a reset"): http://marc.info/?l=linux-arm-kernel&m=133410322617245&w=2 Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
d99de7f552fac43e24fd4fb8048d8f21abaea691 |
|
13-Apr-2012 |
Fernando Guzman Lugo <fernando.lugo@ti.com> |
ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data Due to HW limitation, some IPs should not be accessed just after a softreset. Since the current hwmod sequence is accessing the sysconfig register just after the reset, it might lead to OCP bus error in that case. Add a new field in the sysconfig structure to specify a delay in usecs needed after doing a softreset. In the case of the ISS and FDIF modules, the L3 OCP port will be disconnected upon a SW reset. That issue was confirmed with HW simulation and an errata should be available soon. The HW recommendation to avoid that is to wait for 100 OCP clk cycles, before accessing the IP. Considering the worse case (OPP50), the L3 bus will run at 100 MHz, so a 1 usec delay is needed. Add an x2 margin to be safe. Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com> [paul@pwsan.com: dropped FDIF change for now since the hwmod data is not yet upstream; the FDIF change will need to be added later once the FDIF data is merged] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
f9a2f9c3fa76eec55928e8e06f3094c8f01df7cb |
|
13-Mar-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status omap_hwmod_softreset() does not seem to wait for reset status after doing a softreset. Make it use _ocp_softreset() instead which does this correctly. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Anand Gadiyar <gadiyar@ti.com> Cc: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
2800852a079504f35f88e44faf5c9c96318c0cca |
|
13-Mar-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Restore sysc after a reset After a softreset, make sure the sysc settings are correctly restored. Reported-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Shubhrajyoti D <shubhrajyoti@ti.com> [paul@pwsan.com: combined post-reset SYSCONFIG reload code into the _reset() function to avoid duplication and future mistakes] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
2a1cc1445a51e3a81c10d294586756cdb9174469 |
|
05-Apr-2012 |
Govindraj.R <govindraj.raja@ti.com> |
ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available (ex: usb host uhh module) in absence of this flag omap_hwmod_enable/disable_wakeup avoids configuring pad mux wakeup capability. Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases try enabling/disabling wakeup from mux_pad pins. Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Govindraj.R <govindraj.raja@ti.com> [paul@pwsan.com: updated function kerneldoc documentation] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
387ca5bf4fe2297c93869b6f639afa8d849fb877 |
|
12-Mar-2012 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP: hwmod: Use sysc_fields->srst_shift and get rid of hardcoded SYSC_TYPE2_SOFTRESET_MASK This is useful when we have broken type2 compliant IPs' where the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT and hence is overridden using sysc_fields->srst_shift. We have at least one such instance now with onchip keypad on OMAP5 which has a different softreset shift as compared to other type2 IPs'. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Balaji TK <balajitk@ti.com> Tested-by: Sourav Poddar <sourav.poddar@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
4f8a428dac431e7bd09673b404769d87df948eef |
|
07-Feb-2012 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: omap: fix wrapped error messages in omap_hwmod.c While trying to debug my OMAP platforms, they emitted this message: omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state The following backtrace said it was from a function called '_enable', which didn't provide much clue. Grepping didn't find it either. The message is wrapped, so unwrap the message so grep can find it. Do the same for three other messages in this file. Acked-by: Paul Walmsley <paul@pwsan.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
bfc141e3a515008d85e57af39c9faa4d2bbc65e0 |
|
17-Dec-2011 |
Benoit Cousson <b-cousson@ti.com> |
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported If the module does not have any modulemode, the _disable_module function will do nothing. There is then no point waiting for a idle status change. It will remove the following warnings. [ 0.331848] omap_hwmod: dmm: _wait_target_disable failed [ 0.339935] omap_hwmod: emif_fw: _wait_target_disable failed [ 0.348358] omap_hwmod: l3_main_1: _wait_target_disable failed [ 0.356964] omap_hwmod: l3_main_2: _wait_target_disable failed [ 0.365600] omap_hwmod: l4_abe: _wait_target_disable failed [ 0.373931] omap_hwmod: l4_cfg: _wait_target_disable failed [ 0.382263] omap_hwmod: l4_per: _wait_target_disable failed [ 0.391113] omap_hwmod: l4_wkup: _wait_target_disable failed [ 0.399536] omap_hwmod: dma_system: _wait_target_disable failed [ 0.408325] omap_hwmod: dss_core: _wait_target_disable failed [ 0.416839] omap_hwmod: dss_dispc: _wait_target_disable failed [ 0.425445] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 0.433990] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 0.442504] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 0.451019] omap_hwmod: dss_rfbi: _wait_target_disable failed [ 0.459564] omap_hwmod: dss_venc: _wait_target_disable failed [ 0.489471] omap_hwmod: mailbox: _wait_target_disable failed [ 0.505920] omap_hwmod: spinlock: _wait_target_disable failed Note: For such module, the state is managed automatically by HW according to clock domain transition. It is then not possible to wait for idle even later in the _idle function since the status will change at clock domain boundary. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: renamed fns to indicate that they are OMAP4-only; moved _wait_target_disable() into _disable_module(), removing duplicate code] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
aacf094128759cfb29a3ce88f92d08b79b74a4e8 |
|
16-Dec-2011 |
Rajendra Nayak <rnayak@ti.com> |
ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at init An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in enabled state by the hwmod framework post the initial setup. Once a real user of the device (a driver) tries to enable it at a later point, the hwmod framework throws a WARN() about the device being already in enabled state. Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to identify such devices/hwmods. When the device/hwmod is requested to be enabled (the first time) by its driver/user, nothing except the mux-enable is needed. The mux data is board specific and is unavailable during initial enable() of the device, done by the framework as part of setup(). A good example of a such a device is an UART used as debug console. The UART module needs to be kept enabled through the boot, until the UART driver takes control of it, for debug prints to appear on the console. Acked-by: Kevin Hilman <khilman@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use a flag rather than a state; updated commit message; edited some documentation] Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
abc2d5456334d548328978d0b0d22c0e5d44cdcd |
|
16-Dec-2011 |
Tero Kristo <t-kristo@ti.com> |
ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup pad By default all registered pads will trigger mpu_irqs[0]. Now there is an API for selecting used mpu_irq on pad basis, which can be used to trigger different irq handlers for different pads in the same hwmod. Each pad that requires its interrupt to be re-routed this way must have a separate call to omap_hwmod_pad_route_irq(hwmod, pad, irq). Signed-off-by: Tero Kristo <t-kristo@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: moved fn to omap_hwmod.c; separated fn from mux scan_wakeups changes; added kerneldoc] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
eceec00914e3a74b94eea832f9e829c3efcea9bc |
|
16-Dec-2011 |
Govindraj R <govindraj.raja@ti.com> |
ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup Add API to enable IO pad wakeup capability based on mux pad and wake_up enable flag available from hwmod_mux initialization. Use the wakeup_enable flag and enable wakeup capability for the given pads. Wakeup capability will be enabled/disabled during hwmod idle transition based on whether wakeup_flag is set or cleared. If the hwmod is currently idled, and any mux values were changed by _set_idle_ioring_wakeup(), the SCM PADCTRL registers will be updated. Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> [paul@pwsan.com: rearranged code to limit indentation; cleaned up function documentation; removed unused non-static functions; modified to search all hwmod pads, not just dynamic remuxing ones; modified to update SCM regs if hwmod is currently idle and any pads have changed] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
cc1b0765da6078b906772b79ff211b88cc0ae958 |
|
23-Nov-2011 |
sricharan <r.sricharan@ti.com> |
ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs The address spaces, irqs and dma reqs count APIs return the number of corresponding entries in a hwmod including a additional null value or a -1 terminator in the structure introduced recently. More information here: - 212738a4: omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays - 78183f3f: omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays - bc614958: omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays The issue with irqs and dma info was originally reported by Benoit Cousson. The devices which have multiple hwmods and use device_build_ss are broken with this, as their resources are populated with a extra null value, subsequently the probe fails. So fix the API not to include the array terminator in the count. Reported-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimar@ti.com> Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
|
4e65331c6bb4a777bd61a4dac0daa9fc47777b63 |
|
10-Nov-2011 |
Tony Lindgren <tony@atomide.com> |
ARM: 7159/1: OMAP: Introduce local common.h files As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
fc01387302c01899e3cc67d3c81fd4287db9bab9 |
|
09-Jun-2011 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
ARM: OMAP: change get_context_loss_count ret value to int get_context_loss_count functions return context loss count as u32, and zero means an error. However, zero is also returned when context has never been lost and could also be returned when the context loss count has wrapped and goes to zero. Change the functions to return an int, with negative value meaning an error. OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the hsmmc code handles the returned value as an int, with negative value meaning an error, this patch actually fixes hsmmc code also. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: updated to fix a warning with recent dmtimer changes] Signed-off-by: Tony Lindgren <tony@atomide.com>
|
d6504acd2125984c61dce24727dd3842d0144015 |
|
15-Sep-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: remove OMAP_CHIP* At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and replace it instead with chip family, variant, and ES level-specific lists of hwmods to register. Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the AM3517/3505 support, and for other review comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
|
665d001338b494d6d62810aa99b4c0fa1a0884b9 |
|
10-Jul-2011 |
Rajendra Nayak <rnayak@ti.com> |
OMAP2+: hwmod: Follow the recommended PRCM module enable sequence On OMAP4, the PRCM recommended sequence for enabling a module after power-on-reset is: -1- Force clkdm to SW_WKUP -2- Enabling the clocks -3- Configure desired module mode to "enable" or "auto" -4- Wait for the desired module idle status to be FUNC -5- Program clkdm in HW_AUTO(if supported) This sequence applies to all older OMAPs' as well, however since they use autodeps, it makes sure that no clkdm is in IDLE, and hence not requiring a force SW_WKUP when a module is being enabled. OMAP4 does not need to support autodeps, because of the dyanamic dependency feature, wherein the HW takes care of waking up a clockdomain from idle and hence the module, whenever an interconnect access happens to the given module. Implementing the sequence for OMAP4 requires the clockdomain handling that is currently done in clock framework to be done as part of hwmod framework since the step -4- above to "Wait for the desired module idle status to be FUNC" is done as part of hwmod framework. Signed-off-by: Rajendra Nayak <rnayak@ti.com> [b-cousson@ti.com: Adapt it to the new clkdm hwmod attribute and API] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> [paul@pwsan.com: dropped mach-omap2/clock.c changes; modified to only call the clockdomain code if oh->clkdm is set; disable clock->clockdomain interaction on OMAP4] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
45c38252d76a96e6e0e05f982ca44096191a8eea |
|
10-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP4: hwmod: Introduce the module control in hwmod control Take advantage of the explicit modulemode control to fix the way parents clocks are managed. A module must be disabled before any parents are disabled. That programming model was not possible with the previous implementation that was considering a modulemode as a leaf clock node managed by the clock fmwk. This was leading to bad crash upon disable when the parent clock was gated before the module completed its transition to idle. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
eaac329dfa6d3a4025242bf34d33aa3cb9df9f9f |
|
10-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP4: hwmod: Replace RSTCTRL absolute address with offset macros The RSTCTRL register was accessed using an absolute address. The usage of hardcoded macros to calculate virtual address from physical one should be avoided as much as possible. The usage of an offset will allow future improvement like migration from the current architecture code toward a module driver. Update prm_xxx accessors, move definition to the proper header file and update copyrights. Change the s16 register offset parameter to u16. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use '_prminst_' in function names that are part of the prminst44xx.c file] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
11b10341bd12c87a8409c69cdcd7ee898400842f |
|
10-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Wait the idle status to be disabled It is mandatory to wait for a module to be in disabled state before potentially disabling source clock or re-asserting a reset. omap_hwmod_idle and omap_hwmod_shutdown does not wait for the module to be fully idle. Add a cm_xxx accessor to wait the clkctrl idle status to be disabled. Fix hwmod_[idle|shutdown] to use this API. Based on Rajendra's initial patch. Please note that most interconnects hwmod will return one timeout because it is impossible for them to be in idle since the processor is accessing the registers though the interconnect. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Todd Poynor <toddpoynor@google.com> [paul@pwsan.com: move cpu_is_*() tests to the top of _wait_target_disable(); incorporate some feedback from Todd] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
d0f0631ddc61026dca71b5b679803000d70fde50 |
|
10-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP4: hwmod: Replace CLKCTRL absolute address with offset macros The CLKCTRL register was accessed using an absolute address. The usage of hardcoded macros to calculate virtual address from physical one should be avoided as much as possible. The usage of a offset will allow future improvement like migration from the current architecture code toward a module driver. Update cm_xxx accessor, move definition to the proper header file and update copyrights. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Todd Poynor <toddpoynor@google.com> [paul@pwsan.com: renamed 'omap4_cm_' fns to 'omap4_cminst_'; removed empty fn prototype section from cm44xx.h; incorporated comments from Todd; documented some functions] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6ae769973adf1325115d0dfe3fec17e26cbacd81 |
|
10-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Init clkdm field at boot time At boot time, lookup the clkdm_name to get the clkdm structure pointer for further usage. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6d3c55fd4f0f94a9455d30df9414ddb0f755f402 |
|
10-Jul-2011 |
Avinash.H.M <avinashhm@ti.com> |
OMAP: hwmod: fix the i2c-reset timeout during bootup The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a special sequence to reset the module. The sequence is - Disable the I2C. - Write to SOFTRESET bit. - Enable the I2C. - Poll on the RESETDONE bit. The sequence is implemented as a function and the i2c_class is updated with the correct 'reset' pointer. omap_hwmod_softreset function is implemented which triggers the softreset by writing into sysconfig register. On following this sequence, i2c module resets properly and timeouts are not seen. Cc: Rajendra Nayak <rnayak@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Avinash.H.M <avinashhm@ti.com> [paul@pwsan.com: combined this patch with a patch to remove HWMOD_INIT_NO_RESET from the 44xx hwmod flags; change register offset conditional code to use the IP block revision; minor code cleanup] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
bc6149587b309e3231e5ac7138b84197813e17ec |
|
10-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: use a terminator record with omap_hwmod_dma_info arrays Previously, struct omap_hwmod_dma_info arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_dma_info arrays and uses a sentinel value (irq == -1) as the array terminator instead. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
212738a4499d278254ed6fdb400e3b4be4cb1de2 |
|
10-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: use a terminator record with omap_hwmod_mpu_irqs arrays Previously, struct omap_hwmod_mpu_irqs arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_mpu_irqs arrays and uses a sentinel value (irq == -1) as the array terminator instead. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
78183f3fdf76f422431a81852468be01b36db325 |
|
10-Jul-2011 |
Paul Walmsley <paul@pwsan.com> |
omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays Previously, struct omap_hwmod_addr_space arrays were unterminated; and users of these arrays used the ARRAY_SIZE() macro to determine the length of the array. However, ARRAY_SIZE() only works when the array is in the same scope as the macro user. So far this hasn't been a problem. However, to reduce duplicated data, a subsequent patch will move common data to a separate, shared file. When this is done, ARRAY_SIZE() will no longer be usable. This patch removes ARRAY_SIZE() usage for struct omap_hwmod_addr_space arrays and uses a null structure member as the array terminator instead. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
34617e2a4d331fdd8172077d8c70a0421fc136e6 |
|
01-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Move pr_debug to improve the readability Move the pr_debug at the top of the function to trace the entry even if the first test is failing. That help understanding that we entered the function but failed in it. Move the _enable last part out of the test to reduce indentation and improve readability. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6652271a2556c086c04658dce16de2947e849ffd |
|
01-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Add warnings if enable failed Change the debug into warning to check what IPs are failing. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
31f62866c578b3d47ef7810b336e9e193b90167f |
|
01-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Fix the HW reset management The HW reset must be de-assert after the clocks are enabled but before waiting for the target to be ready. Otherwise the reset might not work properly since the clock is not running to proceed the reset. De-assert the reset after _enable_clocks and before _wait_target_ready. Re-assert it only when the clocks are disabled. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
d24bcaa3fa711f7dd9c4aacf3c58083cf666418f |
|
01-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Remove _populate_mpu_rt_base warning It is perfectly valid for some hwmod to not have any register target address for sysconfig. This is especially true for interconnect hwmods. Remove the warning. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
1fe741139be5acfe3758b53cdbf0b5e3d26db3fe |
|
01-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Do not write the enawakeup bit if SYSC_HAS_ENAWAKEUP is not set The Type 2 type of IPs will not have any enawakeup bit in their sysconfig. Writing to that bit will instead trigger a softreset. Check the flag to write this bit only if the module supports it. Reported-by: Miguel Vadillo <vadillo@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6481c73c22613660a5b791d2b4d0faf60508d731 |
|
01-Jul-2011 |
Miguel Vadillo <vadillo@ti.com> |
OMAP2+: hwmod: Enable module in shutdown to access sysconfig When calling the shutdown, the module may be already in idle. Accessing the sysconfig register will then lead to a crash. In that case, re-enable the module in order to allow the access to the sysconfig register. Signed-off-by: Miguel Vadillo <vadillo@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
724019b0137acf2ea43e5ca854798851f5ebf51f |
|
01-Jul-2011 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Fix smart-standby + wakeup support The commit 86009eb326afde34ffdc5648cd344aa86b8d58d4 was adding the wakeup support for new OMAP4 IPs. This support is incomplete for busmaster IPs that need as well to use smart-standby with wakeup. This new standbymode is suported on HSI and USB_HOST_FS for the moment. Add the new MSTANDBY_SMART_WKUP flag to mark the IPs that support this capability. Enable this new mode when applicable in _enable_wakeup, _disable_wakeup, _enable_sysc and _idle_sysc. The omap_hwmod_44xx_data.c will have to be updated to add this new flag. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Djamil Elaidi <d-elaidi@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
30ebad9d756a0b2c97c6c4ca6c5e6b799e3b64da |
|
01-Jun-2011 |
Govindraj.R <govindraj.raja@ti.com> |
OMAP2+: mux: fix compilation warnings Fix below compilation warnings. arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each': arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used uninitialized in this function arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_gpio': arch/arm/mach-omap2/mux.c:917: warning: 'm' may be used uninitialized in this function Signed-off-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
029268e4c124a38b11ae965849ea2dfef724a568 |
|
11-Mar-2011 |
Tony Lindgren <tony@atomide.com> |
omap2+: Add separate list for dynamic pads to mux This avoids going through the list unnecessarily when idling devices for runtime PM. Based on an earlier patch by sricharan <r.sricharan@ti.com>. Signed-off-by: sricharan <r.sricharan@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
570b54c7fae65b65320d5a7d4b2249c86eeaa497 |
|
10-Mar-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: clockdomain: add flag that will block autodeps from being added for a clockdomain Add a new clockdomain flag, CLKDM_NO_AUTODEPS, which, when marked on a clockdomain, will prevent "autodeps" from being associated with the clockdomain. ("Autodeps" are sleep dependencies and wakeup dependencies from/to processor modules that are automatically added to a clockdomain when it is in hardware-supervised idle mode. They are deprecated -- a relic from the old CDP trees -- but are still in use for OMAP3.) Also, prevent the hwmod code from adding or removing initiator dependencies for clockdomains with this flag set. This patch should allow others to test which clockdomains actually still need autodeps. Thanks to Kevin Hilman <khilman@ti.com> for noting that the original version should also modify the hwmod code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com>
|
9599217a06da5f5a95794ca9192c14317d441187 |
|
10-Mar-2011 |
Kishon Vijay Abraham I <kishon@ti.com> |
OMAP2+: hwmod: add API to handle autoidle mode Create a new API that forms a wrapper to _set_module_autoidle() to modify the AUTOIDLE bit. This API is intended to be used by drivers that requires direct manipulation of the AUTOIDLE bits in SYSCONFIG register. McBSP driver requires autoidle bit to be enabled/disabled while using sidetone feature. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: restrict the hwmod states that the autoidle bit can be changed in; changed function name; dropped "int" from "unsigned int long"] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
43b01643355672a266b95c4719f47cd1abac4680 |
|
10-Mar-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: allow board files to prevent devices from being reset upon init Some boards can't tolerate IP blocks being reset when they are initialized. Michael Büsch cites a case with the Nokia N810: http://www.spinics.net/lists/linux-omap/msg47277.html To allow such boards to continue working normally, allow board file maintainers to mark IP blocks to prevent them from being reset upon init. This is done via a hwmod function, omap_hwmod_no_setup_reset(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Michael Buesch <mb@bu3sch.de>
|
cc1226e7635011c7dd1e786770ed51ee751800f2 |
|
04-Mar-2011 |
omar ramirez <omar.ramirez@ti.com> |
OMAP2+: hwmod: use status bit info for reset line On OMAP2 and OMAP3 the reset ctrl shift doesn't match the status bit, as it does on OMAP4, when handling the reset lines. This patch adds a new member in the reset info structure, so now it can be added as part of hwmod data, and checked accordingly for OMAP2 or 3; otherwise, there could be cases when the shift masks doesn't match both of the registers, and a successful reset might throw an error message or vice versa. Signed-off-by: Omar Ramirez Luna <omar.ramirez@ti.com> [paul@pwsan.com: added a warning if st_shift used on OMAP4; renamed 'r' variable; improved some documentation] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
09c35f2fee8a8633dde7b8b588b1cb496eb220a1 |
|
16-Feb-2011 |
Rajendra Nayak <rnayak@ti.com> |
OMAP2+: hwmod: Fix what _init_clock returns _init_clock always returns 0 and does not propogate the error (in case of failure) back to the caller, causing _init_clocks to fail silently. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
8985b63d072413f0446fd2d0d654795f2d683323 |
|
03-Mar-2011 |
Tarun Kanti DebBarma <tarun.kanti@ti.com> |
OMAP2+: hwmod: fix incorrect computation of autoidle_mask Autoidle is a single bit, TIOCP_CFG[0], setting on OMAP1/2/3/4 platforms. In _set_module_autoidle() I am seeing 0x3 value where the mask is computed. This should be 0x1. v2: (1) Modified the subject. (2) Modified the description with further specific information. Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tested Info: Boot tested on OMAP 1/2/3/4. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
a2debdbd1ad896a410019c9cf30785cad15930fc |
|
23-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: add ability to setup individual hwmods Add omap_hwmod_setup_one(), which is intended for use early in boot to selectively setup the hwmods needed for system clocksources and clockevents, and any other hwmod that is needed in early boot. omap_hwmod_setup_all() can then be called later in the boot process. The point is to minimize the amount of code that needs to be run early. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Tony Lindgren <tony@atomide.com>
|
48d54f3fd20b435311f295b3bca3570096a2ac83 |
|
23-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: ignore attempts to re-setup a hwmod Previously, if a hwmod had already been set up, and the code attempted to set up the hwmod again, an error would be returned. This is not really useful behavior if we wish to allow the OMAP core code to setup the hwmods needed for the Linux clocksources and clockevents before the rest of the hwmods are setup. So, instead of generating errors, just ignore the attempt to re-setup the hwmod. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
|
569edd705cc4e81a9129b5557f1fb259e21418a9 |
|
23-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: find MPU initiator hwmod during in _register() Move the code that looks for the MPU initiator hwmod to run during the individual hwmod _register() function. (Previously, it ran after all hwmods were registered in the omap_hwmod_late_init() function.) This is done so code can late-initialize a few individual hwmods -- for example, for the system timer -- before the entire set of hwmods is initialized later in boot via omap_hwmod_late_init(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
|
550c8092c55c22db8f843bad070fd1731292a75e |
|
28-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: rename some init functions Rename omap_hwmod_init() to omap_hwmod_register(). Rename omap_hwmod_late_init() to omap_hwmod_setup_all(). Also change all of the callers to reflect the new names. While here, update some copyrights. Suggested by Tony Lindgren <tony@atomide.com>. N.B. The comment in mach-omap2/serial.c may no longer be correct, given recent changes in init order. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
|
bac1a0f0bbf0b11b23fe714826f29fc9aeb35855 |
|
23-Feb-2011 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: allow multiple calls to omap_hwmod_init() There's no longer any reason why we should prevent multiple calls to omap_hwmod_init(). It is now simply used to register an array of hwmods. This should allow a subset of hwmods (e.g., hwmods handling the system clocksource and clockevents) to be registered earlier than the remaining mass of hwmods. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@ti.com>
|
cd5038024d6c92fbe4bf67af91eea5c6fb24a192 |
|
24-Feb-2011 |
Kishon Vijay Abraham I <kishon@ti.com> |
OMAP: hwmod: allow hwmod to provide address space accessible from SDMA Adds support for resource API to get address space info other than just MPU. The drivers can now use platform_get_resource_byname() to get resource of type 'IORESOURCE_MEM' by name. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
e7c7d760859e78a4f47e7be647df683491e420fb |
|
15-Feb-2011 |
Tony Lindgren <tony@atomide.com> |
omap: hwmod: Populate _mpu_rt_va later on in omap_hwmod_late_init Otherwise ioremap can fail with early_init patch unless we have a static mapping for everything. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
44dc046e93eb98d41048954f700b1927f7e288ed |
|
15-Feb-2011 |
Tony Lindgren <tony@atomide.com> |
omap2+: Make omap_hwmod_late_init into core_initcall Otherwise things will fail with early_init changes. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
8d9af88f55be89fa4c897ded3204ef12c947731e |
|
23-Dec-2010 |
Tony Lindgren <tony@atomide.com> |
omap2+: Allow hwmod state changes to mux pads based on the state changes Allow hwmod state changes to mux pads based on the state changes. By default, only enable and disable the pads. In some rare cases dynamic remuxing for the idles states is needed, this can be done by passing the enable, idle, and off pads from board-*.c file along with OMAP_DEVICE_PAD_REMUX flag. Thanks to Paul Walmsley <paul@booyaka.com> for the comments on the hwmod related changes. Signed-off-by: Tony Lindgren <tony@atomide.com>
|
c80705aa7074045e7431ed2ebeb0f7d5773615ab |
|
22-Dec-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP: PM: implement context loss count APIs Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by creating similar APIs at the omap_device and omap_hwmod levels. The omap_hwmod level call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to get the context loss count. The new APIs return an unsigned value that can wrap as the context-loss count grows. However, the wrapping is not important as the role of this function is to determine context loss by checking for any difference in subsequent calls to this function. Note that these APIs at each level can return zero when no context loss is detected, or on errors. This is to avoid returning error codes which could potentially be mistaken for large context loss counters. NOTE: only works for devices which have been converted to use omap_device/omap_hwmod. Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the omap_device level API. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
86009eb326afde34ffdc5648cd344aa86b8d58d4 |
|
22-Dec-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs The new OMAP4 IPs introduced a new idle mode named smart-idle with wakeup. This new idlemode replaces the enawakeup for the new IPs but seems to coexist as well for some legacy IPs (UART, GPIO, MCSPI...) Add the new SIDLE_SMART_WKUP flag to mark the IPs that support this capability. The omap_hwmod_44xx_data.c will have to be updated to add this new flag. Enable this new mode when applicable in _enable_wakeup, _enable_sysc and _idle_sysc. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Tested-by: Sebastien Guiriec <s-guiriec@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
|
f2dd7e09db3e18e4c053810b72fe026685d9bf0c |
|
22-Dec-2010 |
Rajendra Nayak <rnayak@ti.com> |
OMAP2+: hwmod: Disable clocks when hwmod enable fails In cases where a module (hwmod) does not become accesible on enabling the main clocks (can happen if there are external clocks needed for the module to become accesible), make sure the clocks are not left enabled. This ensures that when the requisite external dependencies are met a omap_hwmod_enable and omap_hwmod_idle/shutdown would rightly enable and disable clocks using clk framework. Leaving the clocks enabled in the error case causes additional usecounting at the clock framework level leaving the clock enabled forever. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
ce35b2446945c506cb02960eab2072f56efdf1c0 |
|
22-Dec-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Remove omap_hwmod_mutex The hwmod list will be built are init time and never be modified at runtime. There is no need anymore to protect the list from concurrent accesses using a mutex. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
01592df95049a6f3d4abb0571ae1c7cb6e9d1cd7 |
|
22-Dec-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Mark functions used only during initialization with __init _register, _find_mpu_port_index and _find_mpu_rt_base are static APIs that will be used only during the omap_hwmod initialization phase. There is no need to keep them for runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
0102b62789af5aed92cea4cf7f36afaa1ab12c72 |
|
22-Dec-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister Do not allow omap_hwmod_register to be used outside the core hwmod code. An omap_hwmod should be registered only at init time. Remove the omap_hwmod_unregister that is not used today since the hwmod list will be built once at init time and never be modified at runtime. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
5a7ddcbdaf1bb7603422fb6188156ccc39711b0f |
|
22-Dec-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency In the omap_hwmod core, most of the SYSCONFIG register helper functions do not directly write the register, but instead just modify a value passed in. This patch converts the _enable_wakeup() and _disable_wakeup() helper functions to take a value argument and only modify it instead of actually writing the register. This makes the wakeup helpers consistent with the other helper functions and avoids unintentional problems like the following. This problem was found after discovering that GPIO wakeups were no longer functional. The root cause was that the ENAWAKEUP bit of the SYSCONFIG register was being unintentionaly overwritten, leaving wakeups disabled after the following two commits were combined: commit: 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed OMAP: hwmod: Enable module wakeup if in smartidle commit: 78f26e872f77b6312273216de1a8f836c6f2e143 OMAP: hwmod: Set autoidle after smartidle during _sysc_enable There resulting in code in _enable_sysc() was this: /* * XXX The clock framework should handle this, by * calling into this code. But this must wait until the * clock structures are tagged with omap_hwmod entries */ if ((oh->flags & HWMOD_SET_DEFAULT_CLOCKACT) && (sf & SYSC_HAS_CLOCKACTIVITY)) _set_clockactivity(oh, oh->class->sysc->clockact, &v); _write_sysconfig(v, oh); so here, 'v' has wakeups disabled. /* If slave is in SMARTIDLE, also enable wakeup */ if ((sf & SYSC_HAS_SIDLEMODE) && !(oh->flags & HWMOD_SWSUP_SIDLE)) _enable_wakeup(oh); Here wakeup is enabled in the SYSCONFIG register (but 'v' is not updated) /* * Set the autoidle bit only after setting the smartidle bit * Setting this will not have any impact on the other modules. */ if (sf & SYSC_HAS_AUTOIDLE) { idlemode = (oh->flags & HWMOD_NO_OCP_AUTOIDLE) ? 0 : 1; _set_module_autoidle(oh, idlemode, &v); _write_sysconfig(v, oh); } And here, SYSCONFIG is updated again using 'v', which does not have wakeups enabled, resulting in ENAWAKEUP being cleared. Special thanks to Benoit Cousson for pointing out that wakeups were supposed to be automatically enabled when a hwmod is enabled, and thus helping target the root cause of this problem. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
|
72e06d087204f3bc9acf281717b90ebf0b9731f7 |
|
22-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: powerdomain: move header file from plat-omap to mach-omap2 The OMAP powerdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/powerdomain.h to mach-omap2/powerdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access powerdomain code and data directly. As part of this process, remove the references to powerdomain data from the GPIO "driver" and the OMAP PM no-op layer, both in plat-omap. Change the DSPBridge code to point to the new location for the powerdomain headers. The DSPBridge code should not be including the powerdomain headers; these should be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com>
|
1540f214065982e6cbc6b8da1fe65a15e358f7c5 |
|
22-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: clockdomain: move header file from plat-omap to mach-omap2 The OMAP clockdomain code and data is all OMAP2+-specific. This seems unlikely to change any time soon. Move plat-omap/include/plat/clockdomain.h to mach-omap2/clockdomain.h. The primary point of doing this is to remove the temptation for unrelated upper-layer code to access clockdomain code and data directly. DSPBridge also uses the clockdomain headers for some reason, so, modify it also. The DSPBridge code should not be including the clockdomain headers; these should be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
59fb659b065f52fcc2deed293cfbfc58f890376c |
|
21-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files In preparation for adding OMAP4-specific PRCM accessor/mutator functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was OMAP2xxx/3xxx-specific. This process also requires the #includes in each of these files to be changed to reference the new file name. As part of doing so, add some comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use "sideways includes", to indicate that these users of the PRM/CM includes should not be doing so. Thanks to Felipe Contreras <felipe.contreras@gmail.com> for comments on this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
d198b514bd9e94930ee0b9ca1cad0a51f5e29608 |
|
21-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP4: PRCM: reorganize existing OMAP4 PRCM header files Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. Move the "_MOD" macros out of the prcm-common.h header file, into the header file of the hardware module that they belong to. For example, OMAP4430_PRM_*_MOD macros have been moved into the prm44xx.h header. Adjust #includes of all files that used the old PRCM header file names to point to the new filenames. The autogeneration scripts have been updated accordingly. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
233cbe5b94096f95ba7bca2162d63275b0b90b5b |
|
14-Dec-2010 |
Rajendra Nayak <rnayak@ti.com> |
OMAP2+: hwmod: Update the sysc_cache in case module context is lost Do not skip the sysc programming in the hmwod framework based on the cached value alone, since at times the module might have lost context (due to the Powerdomain in which the module belongs transitions to either Open Switch RET or OFF). Identifying if a module has lost context requires atleast one register read, and since a register read has more latency than a write, it makes sense to do a blind write always. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
dc6d1cda044b24c3d9f8e4af0431887ebe3488ef |
|
14-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock Change the per-hwmod mutex to a spinlock. (The per-hwmod lock serializes most post-initialization hwmod operations such as enable, idle, and shutdown.) Spinlocks are needed, because in some cases, hwmods must be enabled from timer interrupt disabled-context, such as an ISR. The current use-case that is driving this is the OMAP GPIO block ISR: it can trigger interrupts even with its clocks disabled, but these clocks are needed for register accesses in the ISR to succeed. This patch also effectively reverts commit 848240223c35fcc71c424ad51a8e8aef42d3879c - this patch makes _omap_hwmod_enable() and _omap_hwmod_init() static, renames them back to _enable() and _idle(), and changes their callers to call the spinlocking versions. Previously, since omap_hwmod_{enable,init}() attempted to take mutexes, these functions could not be called while the timer interrupt was disabled; but now that the functions use spinlocks and save and restore the IRQ state, it is appropriate to call them directly. Kevin Hilman <khilman@deeprootsystems.com> originally proposed this patch - thanks Kevin. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
bd36179eec2827cd60b4a8c6e180cc030c74a4ec |
|
14-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: add support for per-class custom device reset functions The standard omap_hwmod.c _reset() code relies on an IP block's OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This works for most IP blocks on the chip, but unfortunately not all. For example, initiator-only IP blocks often don't have any MPU-accessible OCP-header registers, and therefore the MPU can't write to any OCP_SYSCONFIG registers in that block. Other IP blocks, such as the IVA and I2C, require a specialized reset sequence. Since we need to be able to reset these IP blocks as well, allow custom IP block reset functions to be passed into the hwmod code via a per-hwmod-class reset function pointer, struct omap_hwmod_class.reset. If .reset is non-null, then the hwmod _reset() code will call the custom function instead of the standard OCP SOFTRESET-based code. As part of this change, rename most of the existing _reset() function code to _ocp_softreset(), to indicate more clearly that it does not work for all cases. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Paul Hunt <hunt@ti.com> Cc: Stanley Liu <stanley_liu@ti.com>
|
2092e5ccf89db09ebde94e9aabd3c86d5fa05c6c |
|
14-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: add postsetup state Allow board files and OMAP core code to control the state that some or all of the hwmods end up in at the end of _setup() (called by omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in terms of this new postsetup state code. There are two use-cases for this patch: the !CONFIG_PM_RUNTIME case, in which all IP blocks should stay enabled after _setup() finishes; and the MPU watchdog case, in which the watchdog IP block should enter idle if watchdog coverage of kernel initialization is desired, and should be disabled otherwise. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Charulatha Varadarajan <charu@ti.com>
|
e4dc8f507c3066d6fcece988d99b6d766c46af85 |
|
14-Dec-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod: allow custom pre-shutdown functions Some OMAP IP blocks, such as the watchdog timers, cannot be completely shut down via the standard hwmod shutdown mechanism. This patch enables the hwmod data files to supply a pointer to a custom pre-shutdown function via the struct omap_hwmod_class.pre_shutdown function pointer. If the struct omap_hwmod_class.pre_shutdown function pointer is non-null, the function will be executed before the existing hwmod shutdown code runs. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
cc7a1d2a540a780066aa562c651a88dd28b6fc8a |
|
08-Oct-2010 |
Rajendra Nayak <rnayak@ti.com> |
omap: hwmod: Handle modules with 16bit registers Some modules which have 16bit registers can cause imprecise aborts if a __raw_readl/writel is used to read/write 32 bits. Add an additional flag to identify modules which have such hard requirement, and handle it in the hwmod framework. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
78f26e872f77b6312273216de1a8f836c6f2e143 |
|
24-Sep-2010 |
Hema HK <hemahk@ti.com> |
OMAP: hwmod: Set autoidle after smartidle during _sysc_enable OMAP USBOTG module has a requirement to set the autoidle bit only after setting smartidle bit. Modified the _sys_enable api to set the smartidle first and then the autoidle bit. Setting this will not have any impact on the other modules. Signed-off-by: Hema HK <hemahk@ti.com> Signed-off-by: Partha Basak <p-basak2@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
74ff3a68ed11f1e9eede4fe301f42cc3cdf7396a |
|
21-Sep-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP: hwmod: improve documentation, clean up function names This patch: - adds more documentation to the hwmod code - fixes some documentation typos elsewhere in the file - changes the _sysc_*() function names to appear in (verb, noun) order, to match the rest of the function names. This patch should not result in any functional change. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
9980ce53c97392a3dbdc9d1ac3e455d79b4167ed |
|
21-Sep-2010 |
Rajendra Nayak <rnayak@ti.com> |
OMAP: hwmod: Enable module wakeup if in smartidle If a module's OCP slave port is programmed to be in smartidle, its also necessary that they have module level wakeup enabled. Update _sysc_enable in hwmod framework to do this. The thread "[PATCH 7/8] : Hwmod api changes" archived here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34212.html has additional technical information on the rationale of this patch. Sergei Shtylyov <sshtylyov@mvista.com> identified an indentation problem with this patch - thanks, Sergei. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Partha Basak <p-basak2@ti.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> [paul@pwsan.com: revised patch description] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com>
|
96835af970e5d6aeedf868e53590a947be5e4a7a |
|
21-Sep-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Fix softreset for modules with optional clocks Some modules (like GPIO, DSS...) require optionals clock to be enabled in order to complete the sofreset properly. Add a HWMOD_CONTROL_OPT_CLKS_IN_RESET flag to force all optional clocks to be enabled before reset. Disabled them once the reset is done. TODO: For the moment it is very hard to understand from the HW spec, which optional clock is needed and which one is not. So the current approach will enable all the optional clocks. Paul proposed a much finer approach that will allow to tag only the needed clock in the optional clock table. This might be doable as soon as we have a clear understanding of these dependencies. Reported-by: Partha Basak <p-basak2@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
2cb068149c365f1c2b10f2ece6786139527dcc16 |
|
21-Sep-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Fix softreset status check for some new OMAP4 IPs In OMAP3 a specific SYSSTATUS register was used to get the softreset status. Starting in OMAP4, some IPs does not have SYSSTATUS register and instead use the SYSC softreset bit to provide the status. Other cases might exist: - Some IPs like McBSP does have a softreset control but no reset status. - Some IPs that represent subsystem, like the DSS, can contains a reset status without softreset control. The status is the aggregation of all the sub modules reset status. - Add a new flag (SYSC_HAS_RESET_STATUS) to identify the new programming model and replace the previous SYSS_MISSING, that was used to flag IP with softreset control but without the SYSSTATUS register, with a specific SYSS_HAS_RESET_STATUS flag. - MCSPI and MMC contains both programming models, so the legacy one will be prevented by removing the syss offset field that become useless. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
|
aee48e3c9cee3698d17b4cf4203551de0a804760 |
|
21-Sep-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP: hwmod: add an hardreset API for use by other core code Expose an hardreset API from hwmod in order to assert / deassert all the individual reset lines that belong to an hwmod. This API is needed by some of the more complicated processor drivers, e.g., DSP/Bridge, Syslink, etc. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
76e5589e5b7cd0fd589264ab193f10550e1d8ab6 |
|
21-Sep-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Force a softreset during _setup Force the softreset of every IPs during the _setup phase. IPs that cannot support softreset or that should not be reset must set the HWMOD_INIT_NO_RESET flag in the hwmod struct. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
|
5365efbe29250a227502256cc912351fe2157b42 |
|
21-Sep-2010 |
Benoît Cousson <b-cousson@ti.com> |
OMAP: hwmod: Add hardreset management support Most processor IPs does have a hardreset signal controlled by the PRM. This is different of the softreset used for local IP reset from the SYSCONFIG register. The granularity can be much finer than orginal HWMOD, for ex, the IVA hwmod contains 3 reset lines, the IPU 3 as well, the DSP 2... Since this granularity is needed by the driver, we have to ensure than one hwmod exist for each hardreset line. - Store reset lines as hwmod resources that a driver can query by name like an irq or sdma line. - Add two functions for asserting / deasserting reset lines in hwmods processor that require manual reset control. - Add one functions to get the current reset state. - If an hwmod contains only one line, an automatic assertion / de-assertion is done. -> de-assert the hardreset line only during enable from disable transition -> assert the hardreset line only during shutdown Note: The hwmods with hardreset line and HWMOD_INIT_NO_RESET flag must be kept in INITIALIZED state. They can be properly enabled only if the hardreset line is de-asserted before. For information here is the list of IPs with HW reset control on an OMAP4430 device: RM_DSP_RSTCTRL 1,1,'RST2','RW','1','DSP - MMU, cache and slave interface reset control' 0,0,'RST1','RW','1','DSP - DSP reset control' RM_IVA_RSTCTRL 2,2,'RST3','RW','1','IVA logic and SL2 reset control' 1,1,'RST2','RW','1','IVA Sequencer2 reset control' 0,0,'RST1','RW','1','IVA sequencer1 reset control' RM_IPU_RSTCTRL 2,2,'RST3','RW','1','IPU MMU and CACHE interface reset control.' 1,1,'RST2','RW','1','IPU Cortex M3 CPU2 reset control.' 0,0,'RST1','RW','1','IPU Cortex M3 CPU1 reset control.' PRM_RSTCTRL 1,1,'RST_GLOBAL_COLD_SW','RW','0','Global COLD software reset control.' 0,0,'RST_GLOBAL_WARM_SW','RW','0','Global WARM software reset control.' RM_CPU0_CPU0_RSTCTRL RM_CPU1_CPU1_RSTCTRL 0,0,'RST','RW','0','Cortex A9 CPU0&1 warm local reset control' Signed-off-by: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: made the hardreset functions static; moved the register twiddling into prm*.c functions in previous patches; changed the function names to conform with hwmod practice] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
|
12b1fdb45c2594070bb36e39cd89a33547aad8fb |
|
21-Sep-2010 |
Kevin Hilman <khilman@ti.com> |
OMAP: hwmod: separate list locking and hwmod hardware locking Currently omap_hwmod_mutex is being used to protect both the list access/modification and concurrent access to hwmod functions. This patch separates these two types of locking. First, omap_hwmod_mutex is used only to protect access and modification of omap_hwmod_list. Also cleaned up some comments referring to this mutex that are no longer needed. Then, for protecting concurrent access to hwmod functions, use a per-hwmod mutex. This protects concurrent access to a single hwmod, but would allow concurrent access to different hwmods. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: added structure documentation; changed mutex variable name] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
9b579114efc4bd00532de33c783b4cb4638910ff |
|
21-Sep-2010 |
Liam Girdwood <lrg@slimlogic.co.uk> |
OMAP: hwmod: Fix omap_hwmod_reset wrong state test The reset function wrongly used the state flag as a bit mask and was trying to re-enable after a reset. hwmod is still enabled for the PRCM point of view after a softreset so there is no need to re-enable. Remove the state check from omap_hwmod_reset since the _reset function is checking that as well and in addition can generate a warning Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk> [b-cousson@ti.com: remove the wrong test, remove the re-enable] Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
|
3827f9492bdff045ae57fe67e65ce7e259ed4219 |
|
21-Sep-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Do not disable clocks if hwmod already in idle The disable function was disabling clocks and dependencies from both enable and idle state. Since idle function is already disabling both, an enable -> idle -> disable sequence will try to disable twice the clocks and thus generate a "Trying disable clock XXX with 0 usecount" warning. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
|
9ee9fff92e02e8c5f84794b3a5ce47646c2dfc39 |
|
21-Sep-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Rename dma_ch to dma_req The dma request line attribute was named dma channel, which leads to confusion with the real dma channel definition. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
|
887adeac28a3e354ebb3f9aeca6fc2296c105267 |
|
27-Jul-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2+: hwmod/device: update documentation and copyright Update some minor documentation issues and update copyright for omap_device/omap_hwmod code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
db2a60bf2527209b42e6f512d5892089a835ceaa |
|
27-Jul-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_va Add omap_device_get_mpu_rt_va(). This is intended to be used by device drivers (currently, via a struct platform_data function pointer) to retrieve their corresponding device's virtual base address that the MPU should use to access the device. This is needed because the omap_hwmod code does its own ioremap(), in order to gain access to the module's OCP_SYSCONFIG register. Add omap_hwmod_get_mpu_rt_va(). omap_device_get_mpu_rt_va() calls this function to do the real work. While here, rename struct omap_hwmod._rt_va to struct omap_hwmod._mpu_rt_va, to reinforce that it refers to the MPU's register target virtual address base (as opposed to, for example, the L3's). In the future, this belongs as a function in an omap_bus, so it is not necessary to call this through a platform_data function pointer. The use-case for this function was originally presented by Santosh Shilimkar <santosh.shilimkar@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
97d60162f64ef068b639d8a77ef3bc148baa53ad |
|
27-Jul-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in _setup() On kernels that don't use the omap_device_enable() calls to enable devices, leave all on-chip devices enabled in hwmod _setup(). Otherwise, accesses to those devices are likely to fail, crashing the system. It's expected that kernels built without CONFIG_PM_RUNTIME will be the primary use-case for this. This functionality is controlled by adding an extra parameter to omap_hwmod_late_init(). This patch is based on the patch "OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME" by Kevin Hilman <khilman@deeprootsystems.com>. Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
848240223c35fcc71c424ad51a8e8aef42d3879c |
|
27-Jul-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP: hwmod: add non-locking versions of enable and idle functions Some hwmods may need to be idled/enabled in atomic context, so non-locking versions of these functions are required. Most users should not need these and usage of theses should be controlled to understand why access is being done in atomic context. For this reason, the non-locking functions are only exposed at the hwmod level and not at the omap-device level. The use-case that led to the need for the non-locking versions is hwmods that are enabled/idled from within the core idle/suspend path. Since interrupts are already disabled here, the mutex-based locking in hwmod can sleep and will cause potential deadlocks. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
dc75925d67950889b79df1cc1518c21ec678df6c |
|
24-Jun-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Fix the missing braces As reported by Sergei, a couple of braces were missing after the WARN removal patch. [07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed https://patchwork.kernel.org/patch/100756/ Signed-off-by: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: fixed patch description per Anand's E-mail] Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Cc: Anand Gadiyar <gadiyar@ti.com>
|
4788da268f83dedc58b79dc7b2f6072687f63a19 |
|
19-May-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP powerdomain, hwmod, omap_device: add some credits Add some missing credits for people who have contributed significant features or fixes. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Tero Kristo <tero.kristo@nokia.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Thara Gopinath <thara@ti.com>
|
63403384233e3f58514eea891003458dedd43c12 |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Replace WARN by pr_warning for clockdomain check Most of the clock nodes belong to a clock domain, but it is perfectly valid to have clock without clock domain. Root clocks for example does not belong to any clock domain. Keep the warning but reduce the verbosity. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
5c2c02961ea39d7bbe4d87f362ab3173a424794b |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Rename hwmod name for the MPU In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. The same cleanup will be have to done for other hwmods in OMAP2 & 3 data files. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
|
f5c1f84bcc9c5b7a664886d0a5e7143d0bc3251f |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Do not exit the iteration if one clock init failed During the _init_clocks phase, the iteration is stopped but the status is still change from _HWMOD_STATE_REGISTERED to _HWMOD_STATE_CLKS_INITED. Since the _setup phase will be done nevertheless, it might be better to keep initializing the others clocks nodes and just keep the warning. It is much easier to debug when a important number of clocks name are wrong during the early debug phase of a new platform. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
20383d82160d918047bb10a4f6e170f4bac195a7 |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed The WARN is a little bit too verbose and is not providing usefull information in that case. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
4d3ae5a9a7b3685c6d260a82f4098145862b2cd3 |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Remove IS_ERR check with omap_clk_get_by_name return value The previous clock API was returning a standard linux error code in case of failure. This is not the case anymore with the new omap_clk_get_by_name API. A NULL value means that the clock node does not exist. Replace all the IS_ERR check by a !clk check. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
682fdc96f3afb5ec34e4893fae41d09346d656ed |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP: hwmod: Fix wrong pointer iteration in oh->slaves The iteration is currently done on the omap_hwmod_ocp_if pointer and not on the table pointer that reference them. It worked most of the time because the structure are contiguous in memory. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
33f7ec81fb3e525eec0575f33dbab02240eda6d4 |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP4: hwmod: Replace OCPIF_HAS_IDLEST by HWMOD_NO_IDLEST Some initiator modules in OMAP2 & 3 does not have IDLEST bit, in that case we cannot detect the module readiness by polling that bit and must exist the function immediately assuming that the module is ready. The previous flag was affected to the OCP interface. While it is technically true that the idlest is related to the L4 slave interface of the module, the PRCM status belong to the module. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
9a23dfe12806920a8dfadec5ea5b83e5ca5378c9 |
|
20-May-2010 |
Benoit Cousson <b-cousson@ti.com> |
OMAP4: hwmod & CM: Implement the omap4_cm_wait_module_ready function The return of the omap4_cm_wait_module_ready function is checked in order to avoid accessing the sysconfig register if the module is not in the correct state. In that case the _setup will exit without trying to reset using sysconfig. For the moment a warning is printed. A proper management of fclk and module reset will have to be done in order to init correctly the problematic IPs listed below. <4>omap_hwmod: ivahd: cannot be enabled (3) <4>omap_hwmod: iss: cannot be enabled (3) <4>omap_hwmod: tesla: cannot be enabled (3) <4>omap_hwmod: sdma: cannot be enabled (3) <4>omap_hwmod: sl2: cannot be enabled (3) <4>omap_hwmod: sad2d: cannot be enabled (3) <4>omap_hwmod: ducati: cannot be enabled (3) Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
6262c92f51ffb074800d5a340ee16bc06758e037 |
|
25-Mar-2010 |
Russell King <rmk+kernel@arm.linux.org.uk> |
ARM: Remove useless linux/bootmem.h includes These files include linux/bootmem.h without using anything from this file; remove the unnecessary include. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
d5647c18eac9a313a89a3049a9fff51b20021a44 |
|
31-Mar-2010 |
Thara Gopinath <thara@ti.com> |
OMAP: HWMOD: Adding clockdomain check This patch adds check for presence of clockdomain structure in the API omap_hwmod_get_pwrdm before trying to access the powerdomain structure. This will prevent unnecessary crashing of the system in case of a clock node with out an associated clockdomain. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
43b40992ce21def8d5957f32d7ddb728af89bfce |
|
23-Feb-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP hwmod: add hwmod class support Add support for categorizing and iterating over hardware IP blocks by the "class" of the IP block. The class is the type of the IP block: e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data from the struct omap_hwmod into the struct omap_hwmod_class, since it's expected to stay consistent for each class. While here, fix some comments. The hwmod_class structures in this patch were designed and proposed by Benoît Cousson <b-cousson@ti.com> and were refined in a discussion between Thara Gopinath <thara@ti.com>, Kevin Hilman <khilman@deeprootsystems.com>, and myself. This patch uses WARN() lines that are longer than 80 characters, as Kevin noted a broader lkml consensus to increase greppability by keeping the messages all on one line. Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Benoît Cousson <b-cousson@ti.com> Cc: Thara Gopinath <thara@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
50ebdac2ec9fb2de9c271cb2e0e13aae3b454166 |
|
23-Feb-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev dev+con The OMAP hwmod core code is intended to use SoC IP block description structures that are autogenerated from TI's OMAP hardware database. Currently the hwmod code uses clkdev device + connection addressing to identify clocks. This causes problems in the hwmod autogeneration process, since the TI hardware database doesn't use platform_device or clkdev addressing; it uses a single clock signal name string, which tends to bear some resemblance to what is used in the OMAP TRMs. This patch converts the hwmod code and existing data to use omap_clk_get_by_name(), introduced in the previous patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
358f0e630d5409ab3837b86db3595560eae773b6 |
|
24-Feb-2010 |
Thara Gopinath <thara@ti.com> |
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits. In OMAP3 Some modules like Smartreflex do not have the regular sysconfig register.Instead clockactivity bits are part of another register at a different bit position than the usual bit positions 8 and 9. In OMAP4, a new scheme is available due to the new protocol between the PRCM and the IPs. Depending of the scheme, the SYSCONFIG bitfields position will be different. The IP_REVISION register should be at offset 0x00. It should contain a SCHEME field. From this we can determine whether the IP follows legacy scheme or the new scheme. 31:30 SCHEME Used to distinguish between old scheme and current. Read 0x0: Legacy protocol. Read 0x1: New PRCM protocol defined for new OMAP4 IPs For legacy IP 13:12 MIDLEMODE 11:8 CLOCKACTIVITY 6 EMUSOFT 5 EMUFREE 4:3 SIDLEMODE 2 ENAWAKEUP 1 SOFTRESET 0 AUTOIDLE For new OMAP4 IP's, the bit position in SYSCONFIG is (for simple target): 5:4 STANDBYMODE (Ex MIDLEMODE) 3:2 IDLEMODE (Ex SIDLEMODE) 1 FREEEMU (Ex EMUFREE) 0 SOFTRESET Unfortunately In OMAP4 also some IPs will not follow any of these two schemes. This is the case at least for McASP, SmartReflex and some security IPs. This patch introduces a new field sysc_fields in omap_hwmod_sysconfig which can be used by the hwmod structures to specify the offsets for the sysconfig register of the IP.Also two static structures omap_hwmod_sysc_type1 and omap_hwmod_sysc_type2 are defined which can be used directly to populate the sysc_fields if the IP follows legacy or new OMAP4 scheme. If the IP follows none of these two schemes a new omap_hwmod_sysc_fields structure has to be defined and passed as part of omap_hwmod_sysconfig. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
46273e6f37bdf3801363986e2228350ecad19059 |
|
27-Jan-2010 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP: hwmod: add API for slave idlemode setting Some HW blocks have errata which requires specific slave idle mode under certain conditions. This patch adds an hwmod API to allow setting slave idlemode ensuring that any SYSCONFIG register updates go through hwmod. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
55ed96945b1f3d0f4ad21a27b32ce4bd99d8c268 |
|
27-Jan-2010 |
Paul Walmsley <paul@pwsan.com> |
OMAP2/3 clkdm/pwrdm: move wkdep/sleepdep handling from pwrdm to clkdm Move clockdomain wakeup dependency and sleep dependency data structures from the powerdomain layer to the clockdomain layer, where they belong. These dependencies were originally placed in the powerdomain layer due to unclear documentation; however, it is clear now that these dependencies are between clockdomains. For OMAP2/3, this is not such a big problem, but for OMAP4 this needs to be fixed. Thanks to Benoît Cousson <b-cousson@ti.com> for his advice on this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
883edfdd58419b0cc298db14ba25c26d55c6d1af |
|
20-Jan-2010 |
Thara Gopinath <thara@ti.com> |
OMAP3: hwmod: Adding flag to prevent caching of sysconfig register. In the current implementation the sysconfig value is read into _sysc_cache once and an actual update to the sysconfig register happens only if the new value paased is differnt from the one in _sysc_cache. _sysc_cache is updated only if _HWMOD_SYSCONFIG_LOADED is not set. This can lead to the follwing issue if off mode is enabled in modules which employs "always-retore" mechanism of context save and restore. a. The module sets the sysconfig register through omap_device_enable. Here _sysc_cache is updated with the value written to the sysconfig register and left. b. The power domain containig the module enters off mode and the module context is lost. c. The module in use becomes active and calls omap_device_enable to enable itself. Here a read of sysconfig register does not happen as _HWMOD_SYSCONFIG_LOADED flag is set. The value to be written to the sysconfig register will be same as the one written in step a. Since _sysc_cache reflects the previous written value an update of the sysconfig register does not happen. This means in modules which employs "always-restore" mechanism after off , the sysconfig regsiters will never get updated. This patch introduces a flag SYSC_NO_CACHE which if set ensures that the sysconfig register is always read into _sysc_cache before an update is attempted. This flags need to be set only by modules which does not do a context save but re-initializes the registers every time the module is accessed. This includes modules like i2c, smartreflex etc. Signed-off-by: Thara Gopinath <thara@ti.com> [paul@pwsan.com: tweaked to apply on a different head, added flag comment] Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
81d7c6ffccd1d5369942c428faa9ee25a3d59db8 |
|
09-Dec-2009 |
Kevin Hilman <khilman@deeprootsystems.com> |
OMAP: hwmod: warn on missing clockdomain WARN if a clock/hwmod is missing a clockdomain association since resulting hwmod will not be able to correctly enable/disable clocks. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
a16b1f7f8692163e0c6b4741d8980837dfca75f1 |
|
09-Dec-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP3 hwmod: drop most of the OCP_SYSCONFIG.CLOCKACTIVITY code Earlier, the hwmod code had considered the OCP_SYSCONFIG.CLOCKACTIVITY bits to be incremental power saving bits, controlling internal IP block clock gates. This was a misapprehension. The CLOCKACTIVITY bits are used to indicate, in advance, which clocks will be cut when the module acknowledges an idle request. This enables the IP block to take whatever action is necessary to complete any in-progress work before asserting its IdleAck. In the current Linux-OMAP code, this implies that the clock framework should be changing module CLOCKACTIVITY bits as module clocks are enabled and disabled. We don't do that yet, but in the future, we should. This must wait until the clock tree is annotated with omap_hwmod pointers (or vice-versa). In the meantime, drop most of the hwmod code that controls CLOCKACTIVITY bits to avoid confusion. This patch has benefited from many illuminating discussions with (in alphabetical order) Benoît Cousson <b-cousson@ti.com>, Rajendra Nayak <rnayak@ti.com>, and Sebastien Sabatier <s-sabatier1@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Sebastien Sabatier <s-sabatier1@ti.com> Cc: Benoît Cousson <b-cousson@ti.com>
|
718bfd76932c566f79eb55083693ef0b68071bf8 |
|
09-Dec-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP hwmod: add names to module MPU IRQ lines Replace the existing u8 array of module MPU IRQ lines with a struct that includes a name - similar to the existing struct omap_hwmod_dma_info. Device drivers can then use platform_get_resource_byname() to retrieve specific IRQs without nasty dependencies on array ordering. Thanks to Benoît Cousson <b-cousson@ti.com> and Kevin Hilman <khilman@deeprootsystems.com> for feedback on this approach. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
|
726072e5dd459e3831d1dd4308ba469ff3ded419 |
|
09-Dec-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. After this patch, the hwmod code will set the module AUTOIDLE bit (generally <module>.OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon enable. If the hwmod flag HWMOD_NO_OCP_AUTOIDLE is set, AUTOIDLE will be set to 0 upon enable. Upon module disable, AUTOIDLE will be set to 1. Enabling module autoidle should save some power. The only reason to not set the OCP_SYSCONFIG.AUTOIDLE bit is if there is a bug in the module RTL, e.g., the MPUINTC block on OMAP3. Comments from Kevin Hilman <khilman@deeprootsystems.com> inspired this patch, and Kevin tested an earlier version of this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
|
b835d0142196466c5ff3695b90cff1e3ea635c8e |
|
09-Dec-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP3 hwmod: reprogram OCP_SYSCONFIG register after setting SOFTRESET Reprogram the module's OCP_SYSCONFIG register after module reset (SOFTRESET = 1). This may not be needed, but the definition of the reset performed by the SOFTRESET bit is unclear. Kevin Hilman <khilman@deeprootsystems.com> tested an earlier version of this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
|
6f8b7ff5b01e16a65c3b17865ce047faeca40907 |
|
09-Dec-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP clock/hwmod: fix off-by-one errors Fix loop bailout off-by-one bugs reported by Juha Leppänen <juha_motorsportcom@luukku.com>. This second version incorporates comments from Russell King <linux@arm.linux.org.uk>. A new macro, 'omap_test_timeout', has been created, with cleaner code, and existing code has been converted to use it. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Juha Leppänen <juha_motorsportcom@luukku.com> Cc: Russell King <linux@arm.linux.org.uk>
|
ce491cf85466c3377228c5a852ea627ec5136956 |
|
20-Oct-2009 |
Tony Lindgren <tony@atomide.com> |
omap: headers: Move remaining headers from include/mach to include/plat Move the remaining headers under plat-omap/include/mach to plat-omap/include/plat. Also search and replace the files using these headers to include using the right path. This was done with: #!/bin/bash mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" headers=$(cd $mach_dir_old && ls *.h) omap_dirs="arch/arm/*omap*/ \ drivers/video/omap \ sound/soc/omap" other_files="drivers/leds/leds-ams-delta.c \ drivers/mfd/menelaus.c \ drivers/mfd/twl4030-core.c \ drivers/mtd/nand/ams-delta.c" for header in $headers; do old="#include <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: Tony Lindgren <tony@atomide.com>
|
986a13f508156e1d041d59166beb2a3dec2ddfad |
|
20-Oct-2009 |
Tony Lindgren <tony@atomide.com> |
omap: Use ioremap in omap_hwmod.c Use ioremap in omap_hwmod.c Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
|
02bfc030e4417003b7a94393102c92e39b2dfa65 |
|
03-Sep-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP: omap_hwmod: call omap_hwmod init at boot; create interconnects Connect the omap_hwmod code to the kernel boot. Create some basic interconnect and device structures for OMAP2/3 chips. Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
63c852384125ca0eff0e695f92cbbd439bed4aa3 |
|
03-Sep-2009 |
Paul Walmsley <paul@pwsan.com> |
OMAP2/3/4: create omap_hwmod layer OMAP SoCs can be considered a collection of hardware IP blocks connected by various interconnects. The bus topology and device integration data is somewhat more complex than platform_device can encode. This patch creates code and structures to manage information about OMAP on-chip devices ("hardware modules") and their integration to the rest of the chip. Hardware module data is intended to be generated dynamically from the TI hardware database for the OMAP4 chips and beyond, easing Linux support for new chip variants. This code currently: - resets and configures all hardware modules upon startup, reducing bootloader dependencies; - provides hooks for Linux driver model code to enable, idle, and shutdown hardware modules (forthcoming patch); - waits for hardware modules to leave idle once their clocks are enabled and OCP_SYSCONFIG bits are set appropriately. - provides a means to pass arbitrary IP block configuration data (e.g., FIFO size) to the device driver (via the dev_attr void pointer) In the future this code is intended to: - estimate interconnect bandwidth and latency characteristics to ensure constraints are satisfied during DVFS - provide *GRPSEL bit data to the powerdomain code - handle pin/ball muxing for devices - generate IO mapping information dynamically - supply device firewall configuration data - provide hardware module data to other on-chip coprocessor software - allow the removal of the "disable unused clocks" code in the OMAP2/3 clock code This patch represents a collaborative effort involving many people from TI, Nokia, and the Linux-OMAP community. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Vikram Pandita <vikram.pandita@ti.com> Cc: Sakari Poussa <sakari.poussa@nokia.com> Cc: Anand Sawant <sawant@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Eric Thomas <ethomas@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
|