- 16 6月, 2014 1 次提交
-
-
由 Dave Gerlach 提交于
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: NDave Gerlach <d-gerlach@ti.com> [paul@pwsan.com: fixed build errors for an AM43xx-only Kconfig] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 08 5月, 2014 1 次提交
-
-
由 Victor Kamensky 提交于
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: NVictor Kamensky <victor.kamensky@linaro.org> Signed-off-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 12 4月, 2014 1 次提交
-
-
由 Suman Anna 提交于
Bug was introduced by commit 'f92d9597: 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: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Fixes: f92d9597 ("ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT") Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 20 2月, 2014 1 次提交
-
-
由 Illia Smyrnov 提交于
Commit 313a76ee (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: NIllia Smyrnov <illia.smyrnov@globallogic.com> Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 22 1月, 2014 1 次提交
-
-
由 Santosh Shilimkar 提交于
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: NSantosh 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 18 1月, 2014 2 次提交
-
-
由 Tero Kristo 提交于
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: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NMike Turquette <mturquette@linaro.org>
-
由 Tero Kristo 提交于
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: NTero Kristo <t-kristo@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NMike Turquette <mturquette@linaro.org>
-
- 10 12月, 2013 2 次提交
-
-
由 Nishanth Menon 提交于
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: NNishanth Menon <nm@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Roger Quadros 提交于
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: NRoger 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: NPaul Walmsley <paul@pwsan.com>
-
- 07 12月, 2013 1 次提交
-
-
由 Tony Lindgren 提交于
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 3b9b1015 (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: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 14 10月, 2013 1 次提交
-
-
由 Afzal Mohammed 提交于
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: NAmbresh K <ambresh@ti.com> Signed-off-by: NAfzal Mohammed <afzal@ti.com> Acked-by: NRajendra Nayak <rnayak@ti.com> Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 09 10月, 2013 2 次提交
-
-
由 Rajendra Nayak 提交于
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: NRajendra Nayak <rnayak@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Suman Anna 提交于
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: NSuman Anna <s-anna@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NNishanth Menon <nm@ti.com> Acked-by: NTony 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: NPaul Walmsley <paul@pwsan.com>
-
- 23 8月, 2013 1 次提交
-
-
由 Jon Hunter 提交于
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: NJon Hunter <jon-hunter@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 13 8月, 2013 1 次提交
-
-
由 Rajendra Nayak 提交于
The soc_ops for dra7xx devices can be completed reused from the ones used for omap4 and omap5 devices. Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NR Sricharan <r.sricharan@ti.com>
-
- 30 7月, 2013 1 次提交
-
-
由 Afzal Mohammed 提交于
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: NAfzal Mohammed <afzal@ti.com> Tested-by: NMugunthan V N <mugunthanvnm@ti.com> [paul@pwsan.com: use u8 rather than int to save memory] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 20 5月, 2013 3 次提交
-
-
由 Santosh Shilimkar 提交于
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: NVaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Signed-off-by: NRajendra nayak <rnayak@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: NKevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Rajendra Nayak 提交于
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: NVaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: NKevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Rajendra Nayak 提交于
_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: NVaibhav Bedia <vaibhav.bedia@ti.com> Tested-by: NSourav Poddar <sourav.poddar@ti.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: NKevin Hilman <khilman@linaro.org> Tested-by: Kevin Hilman <khilman@linaro.org> # OMAP4/Panda Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 17 5月, 2013 1 次提交
-
-
由 jean-philippe francois 提交于
_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: NJean-Philippe Fran=C3=A7ois <jp.francois@cynove.com> Acked-by: NKevin Hilman <khilman@linaro.org> [tony@atomide.com: updated description with oops] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 03 5月, 2013 1 次提交
-
-
由 Russell King 提交于
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: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 09 4月, 2013 2 次提交
-
-
由 Santosh Shilimkar 提交于
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: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>
-
由 Santosh Shilimkar 提交于
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: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>
-
- 08 4月, 2013 1 次提交
-
-
由 Thomas Gleixner 提交于
Use the generic idle loop and replace enable/disable_hlt with the respective core functions. Signed-off-by: NThomas 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: NCc: 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
-
- 01 4月, 2013 1 次提交
-
-
由 Rajendra Nayak 提交于
_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: NVaibhav Bedia <vaibhav.bedia@ti.com> Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 14 3月, 2013 1 次提交
-
-
由 Russell King 提交于
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: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 13 3月, 2013 1 次提交
-
-
由 Grazvydas Ignotas 提交于
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: NGrazvydas Ignotas <notasas@gmail.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 11 2月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NSebastien 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>
-
- 08 2月, 2013 1 次提交
-
-
由 Vaibhav Bedia 提交于
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: NVaibhav Bedia <vaibhav.bedia@ti.com> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: NPeter Korsgaard <jacmet@sunsite.dk> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 07 2月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com>
-
- 26 1月, 2013 1 次提交
-
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com>
-
- 12 1月, 2013 1 次提交
-
-
由 Tony Lindgren 提交于
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: NEzequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 22 11月, 2012 2 次提交
-
-
由 Peter Ujfalusi 提交于
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: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NBenoît Cousson <b-cousson@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Rajendra Nayak 提交于
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: NRajendra 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: NTero 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: NPaul Walmsley <paul@pwsan.com>
-
- 13 11月, 2012 3 次提交
-
-
由 Rajendra Nayak 提交于
Clean all #ifdef's added as part of fixing the clkdm accesses from hwmod. Signed-off-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NMike Turquette <mturquette@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Vaibhav Hiremath 提交于
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: NVaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: NMike Turquette <mturquette@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Rajendra Nayak 提交于
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: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NMike Turquette <mturquette@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 09 11月, 2012 3 次提交
-
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Tested-by: NVaibhav Hiremath <hvaibhav@ti.com>
-