- 09 10月, 2010 1 次提交
-
-
由 Rajendra Nayak 提交于
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: NRajendra Nayak <rnayak@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 25 9月, 2010 1 次提交
-
-
由 Hema HK 提交于
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: NHema HK <hemahk@ti.com> Signed-off-by: NPartha 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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 22 9月, 2010 11 次提交
-
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Rajendra Nayak 提交于
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: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NPartha Basak <p-basak2@ti.com> Signed-off-by: NBenoît Cousson <b-cousson@ti.com> [paul@pwsan.com: revised patch description] Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com>
-
由 Benoit Cousson 提交于
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: NPartha Basak <p-basak2@ti.com> Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Benoît Cousson 提交于
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: NBenoit 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: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Kevin Hilman 提交于
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: NKevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: added structure documentation; changed mutex variable name] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Liam Girdwood 提交于
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: NLiam Girdwood <lrg@slimlogic.co.uk> [b-cousson@ti.com: remove the wrong test, remove the re-enable] Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Benoit Cousson 提交于
The dma request line attribute was named dma channel, which leads to confusion with the real dma channel definition. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
-
- 27 7月, 2010 4 次提交
-
-
由 Paul Walmsley 提交于
Update some minor documentation issues and update copyright for omap_device/omap_hwmod code. Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com>
-
由 Kevin Hilman 提交于
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: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 24 6月, 2010 1 次提交
-
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> [paul@pwsan.com: fixed patch description per Anand's E-mail] Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Sergei Shtylyov <sshtylyov@mvista.com> Cc: Anand Gadiyar <gadiyar@ti.com>
-
- 21 5月, 2010 9 次提交
-
-
由 Paul Walmsley 提交于
Add some missing credits for people who have contributed significant features or fixes. Signed-off-by: NPaul 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>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
The WARN is a little bit too verbose and is not providing usefull information in that case. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Benoit Cousson 提交于
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: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 15 5月, 2010 1 次提交
-
-
由 Russell King 提交于
These files include linux/bootmem.h without using anything from this file; remove the unnecessary include. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 31 3月, 2010 1 次提交
-
-
由 Thara Gopinath 提交于
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: NThara Gopinath <thara@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 25 2月, 2010 3 次提交
-
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Signed-off-by: NBenoît Cousson <b-cousson@ti.com> Cc: Thara Gopinath <thara@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Thara Gopinath 提交于
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: NThara Gopinath <thara@ti.com> Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 27 1月, 2010 2 次提交
-
-
由 Kevin Hilman 提交于
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: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
-
- 20 1月, 2010 1 次提交
-
-
由 Thara Gopinath 提交于
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: NThara Gopinath <thara@ti.com> [paul@pwsan.com: tweaked to apply on a different head, added flag comment] Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
- 12 12月, 2009 5 次提交
-
-
由 Kevin Hilman 提交于
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: NKevin Hilman <khilman@deeprootsystems.com> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Paul Walmsley 提交于
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: NPaul 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>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
-
由 Paul Walmsley 提交于
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: NPaul Walmsley <paul@pwsan.com> Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
-