Skip to content

L
linux
Switch branch/tag
  1. 06 Jul, 2012 2 commits
  3. 05 Jul, 2012 7 commits
  5. 04 Jul, 2012 11 commits
    • Paul Walmsley's avatar
      Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and... · 8cb8de5d
      Paul Walmsley authored 
      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
    • Kishon Vijay Abraham I's avatar
      ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework · 6668546f
      Kishon Vijay Abraham I authored 
      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: default avatarKishon Vijay Abraham I <kishon@ti.com>
[paul@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      6668546f
    • R Sricharan's avatar
      ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak · 3f4990f4
      R Sricharan authored 
      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: default avatarR 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: default avatarPaul Walmsley <paul@pwsan.com>
      3f4990f4
    • Tarun Kanti DebBarma's avatar
      ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API · bed9d1bb
      Tarun Kanti DebBarma authored 
      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: default avatarTarun 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: default avatarBenoit Cousson <b-cousson@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      bed9d1bb
    • Vikram Pandita's avatar
      ARM: OMAP3+: dpll: optimize noncore dpll locking logic · 55ffe163
      Vikram Pandita authored 
      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: default avatarVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      55ffe163
    • Sakari Ailus's avatar
      ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL · f0d3d821
      Sakari Ailus authored 
      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: default avatarSakari Ailus <sakari.ailus@iki.fi>
Cc: Vimarsh Zutshi <vimarsh.zutshi@gmail.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      f0d3d821
    • Jon Hunter's avatar
      ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status · d49cae92
      Jon Hunter authored 
      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: default avatarJon Hunter <jon-hunter@ti.com>
Acked-by: default avatarKevin Hilman <khilman@ti.com>
Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: edited commit message slightly]
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      d49cae92
    • Jon Hunter's avatar
      ARM: OMAP4: clockdomain/CM code: Update supported transition modes · 65aa94b2
      Jon Hunter authored 
      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: default avatarBenoit Cousson <b-cousson@ti.com>
Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      65aa94b2
    • Vaibhav Hiremath's avatar
      ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm · 768c69f5
      Vaibhav Hiremath authored 
      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: default avatarVaibhav 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: default avatarPaul Walmsley <paul@pwsan.com>
      768c69f5
    • Vaibhav Hiremath's avatar
      ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx · 248b3b3d
      Vaibhav Hiremath authored 
      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: default avatarVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: default avatarVaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      248b3b3d
    • Tony Lindgren's avatar
      Merge tags 'omap-cleanup-for-v3.6', 'omap-devel-dmtimer-for-v3.6' and... · 3f96a2d9
      Tony Lindgren authored 
      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
  7. 30 Jun, 2012 13 commits
  9. 29 Jun, 2012 7 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7