Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 05 7月, 2012 2 次提交
  3. 04 7月, 2012 11 次提交
    • P
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and... · 8cb8de5d
      由 Paul Walmsley 提交于 
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 'misc_devel_3.6' into omap_devel_f_3.6
      8cb8de5d
    • K
      ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework · 6668546f
      由 Kishon Vijay Abraham I 提交于 
      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: NKishon Vijay Abraham I <kishon@ti.com>
[paul@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      6668546f
    • R
      ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak · 3f4990f4
      由 R Sricharan 提交于 
      Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.

This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
[paul@pwsan.com: unsplit quoted strings; moved PRM functions to
 mach-omap2/prm_common.c; resolved sparse warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      3f4990f4
    • T
      ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API · bed9d1bb
      由 Tarun Kanti DebBarma 提交于 
      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: NTarun 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: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      bed9d1bb
    • V
      ARM: OMAP3+: dpll: optimize noncore dpll locking logic · 55ffe163
      由 Vikram Pandita 提交于 
      If the dpll is already locked, code can be optimized
to return much earlier than doing redundent set of lock mode
and wait on idlest.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Mike Turquette <mturquette@ti.com>
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      55ffe163
    • S
      ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL · f0d3d821
      由 Sakari Ailus 提交于 
      The register is used to configure the behaviour of the CSI-2 and CCP-2
receivers. This register is available only in OMAP3630.

The original patch was submitted by Vimarsh Zutshi.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Cc: Vimarsh Zutshi <vimarsh.zutshi@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f0d3d821
    • J
      ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status · d49cae92
      由 Jon Hunter 提交于 
      The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.

To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current power
state.

This is based upon Tony's current linux-omap master branch.

Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
  Paul's 32k timer patch [1]).

[1] http://marc.info/?l=linux-omap&m=134000053229888&w=2Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: edited commit message slightly]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d49cae92
    • J
      ARM: OMAP4: clockdomain/CM code: Update supported transition modes · 65aa94b2
      由 Jon Hunter 提交于 
      For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
following transition modes ...

NO_SLEEP (0x0) - A clock domain sleep transition is never initiated,
		 irrespective of the hardware conditions.
SW_SLEEP (0x1) - A software-forced sleep transition. The transition is initiated
		 when the associated hardware conditions are satisfied
SW_WKUP  (0x2) - A software-forced clock domain wake-up transition is initiated,
		 irrespective of the hardware conditions.
HW_AUTO  (0x3) - Hardware-controlled automatic sleep and wake-up transition is
		 initiated by the PRCM module when the associated hardware
		 conditions are satisfied.

For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is equivalent
to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP for OMAP4 devices
is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt status is set in case of
SW_SLEEP transition, and not set in case of HW_AUTO transition.

For OMAP4 devices, all CLKDMs support HW_AUTO and therefore we can place the
CLKDMs in the HW_AUTO state instead of the SW_SLEEP mode. Hence, we do not
need to use the SW_SLEEP mode. With regard to NO_SLEEP and SW_WKUP it is
preferred to use SW_WKUP mode if the CLKDM supports it and so use this mode
instead of NO_SLEEP where possible.

For a software perspective the above 4 modes are represented by the following
flags to indicate what modes are supported by each of the CLKDMs.

CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
CLKDM_CAN_FORCE_SLEEP	--> SW_SLEEP
CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP

By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4 devices
can becomes ...

CLKDM_CAN_DISABLE_AUTO	--> NO_SLEEP
CLKDM_CAN_ENABLE_AUTO	--> HW_AUTO
CLKDM_CAN_FORCE_SLEEP	--> HW_AUTO
CLKDM_CAN_FORCE_WAKEUP	--> SW_WKUP

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Reviewed-by: NBenoit Cousson <b-cousson@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NJon Hunter <jon-hunter@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      65aa94b2
    • V
      ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm · 768c69f5
      由 Vaibhav Hiremath 提交于 
      In case of AM33XX device, XXX_RSTST register offset is not
consistent across PRM modules/instances,

PRM_XXX            RSTST
=========================
PRM_PER_MOD:       0x04
PRM_WKUP_MOD:      0x0C
PRM_MPU_MOD:       NA
PRM_DEVICE_MOD:    0x08

This means, we need to pass on XXX_RSTST register offset
information through omap_hwmod data, similar to XXX_RSTCTRL.

Currently, this field is only applicable and used for AM33XX
devices.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      768c69f5
    • V
      ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx · 248b3b3d
      由 Vaibhav Hiremath 提交于 
      In case of AM33xx family of devices (like cpsw) have different sysc
bit field offsets defined,

sysc_type3:
|  3     2  |  1    0  |
| STDBYMODE | IDLEMODE |

So introduce new sysc_type3 in omap_hwmod common data.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      248b3b3d
    • T
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and... · 3f96a2d9
      由 Tony Lindgren 提交于 
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and 'omap-devel-am33xx-for-v3.6' into devel-am33xx-part2
      3f96a2d9
  5. 01 7月, 2012 9 次提交
  7. 30 6月, 2012 9 次提交
  9. 29 6月, 2012 9 次提交