| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-makefile-sparse
smatch and string-wrapping cleanups for the OMAP subarch code.
These changes fix some of the more meaningful warnings that smatch
returns for the OMAP subarch code, and unwraps strings that are
wrapped at the 80-column boundary, to conform with the current
practice.
Basic build, boot, and PM logs are available here:
http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
|
|
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>
|
|
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>
|
|
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>
|
|
Pull arm-soc power management changes from Arnd Bergmann:
"These are various power management related changes, mainly concerning
cpuidle on i.MX and OMAP, as well as a the move of the omap
smartreflex driver to live in the power subsystem."
Fix up conflicts in arch/arm/mach-{imx/mach-imx6q.c,omap2/prm2xxx_3xxx.h}
* tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (37 commits)
ARM: OMAP2+: PM: fix IRQ_NOAUTOEN removal by mis-merge
ARM: OMAP2+: do not allow SmartReflex to be built as a module
ARM: OMAP2: Use hwmod to initialize mmc for 2420
ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
ARM: OMAP3: PM: cpuidle: default to C1 in next_valid_state
ARM: OMAP3: PM: cleanup cam_pwrdm leftovers
ARM: OMAP3: PM: call pre/post transition per powerdomain
ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle
ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during hwmod mux
ARM: OMAP3+: PRM: Enable IO wake up
ARM: OMAP4: PRM: Add IO Daisychain support
ARM: OMAP3: PM: Move IO Daisychain function to omap3 prm file
ARM: OMAP3: PM: correct enable/disable of daisy io chain
ARM: OMAP2+: PRM: fix compile for OMAP4-only build
W1: OMAP HDQ1W: use runtime PM
ARM: OMAP2+: HDQ1W: use omap_device
W1: OMAP HDQ1W: use 32-bit register accesses
W1: OMAP HDQ1W: allow driver to be built on all OMAP2+
...
|
|
Pull support for three new arm SoC types from Arnd Bergmann:
- The mvebu platform includes Marvell's Armada XP and Armada 370 chips,
made by the mvebu business unit inside of Marvell. Since the same
group also made the older but similar platforms we call "orion5x",
"kirkwood", "mv78xx0" and "dove", we plan to move all of them into
the mach-mvebu directory in the future.
- socfpga is Altera's platform based on Cortex-A9 cores and a lot of
FPGA space. This is similar to the Xilinx zynq platform we already
support. The code is particularly clean, which is helped by the fact
that the hardware doesn't do much besides the parts that are expected
to get added in the FPGA.
- The OMAP subarchitecture gains support for the latest generation, the
OMAP5 based on the new Cortex-A15 core. Support is rather
rudimentary for now, but will be extended in the future.
* tag 'newsoc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (25 commits)
ARM: socfpga: initial support for Altera's SOCFPGA platform
arm: mvebu: generate DTBs for supported SoCs
ARM: mvebu: MPIC: read number of interrupts from control register
arm: mach-mvebu: add entry to MAINTAINERS
arm: mach-mvebu: add compilation/configuration change
arm: mach-mvebu: add defconfig
arm: mach-mvebu: add documentation for new device tree bindings
arm: mach-mvebu: add support for Armada 370 and Armada XP with DT
arm: mach-mvebu: add source files
arm: mach-mvebu: add header
clocksource: time-armada-370-xp: Marvell Armada 370/XP SoC timer driver
ARM: Kconfig update to support additional GPIOs in OMAP5
ARM: OMAP5: Add the build support
arm/dts: OMAP5: Add omap5 dts files
ARM: OMAP5: board-generic: Add device tree support
ARM: omap2+: board-generic: clean up the irq data from board file
ARM: OMAP5: Add SMP support
ARM: OMAP5: Add the WakeupGen IP updates
ARM: OMAP5: l3: Add l3 error handler support for omap5
ARM: OMAP5: gpmc: Update gpmc_init()
...
Conflicts:
Documentation/devicetree/bindings/arm/omap/omap.txt
arch/arm/mach-omap2/Makefile
drivers/clocksource/Kconfig
drivers/clocksource/Makefile
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull arm-soc cleanups, part 2, from Arnd Bergmann:
"These omap cleanups have dependencies on earlier omap branches that in
turn depend on other cleanups, so they could not go into the same
branch."
* tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: OMAP: sdrc: Fix the build break for OMAP4 only builds
ARM: OMAP2+: dmtimer: cleanup fclk usage
ARM: OMAP2+: Fix mismerge for omap_hwmod_get_main_clk() API
ARM: OMAP2+: Remove unnecessary ifdef around __omap2_set_globals
ARM: OMAP2+: am33xx: Change cpu_is_am33xx to soc_is_am33xx
ARM: OMAP2+: am33xx: Make am33xx as a separate class
ARM: OMAP2+: Move omap3 dpll ops to dpll3xxx.c
ARM: OMAP2+: All OMAP2PLUS uses omap-device.o target so add one entry
ARM: OMAP: dmtimer: use devm_ API and do some cleanup in probe()
ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework
ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak
ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API
ARM: OMAP3+: dpll: optimize noncore dpll locking logic
ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL
ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status
ARM: OMAP4: clockdomain/CM code: Update supported transition modes
ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm
ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
|
|
Pull general arm-soc cleanups from Arnd Bergmann:
"These are all boring changes, moving stuff around or renaming things
mostly, and also getting rid of stuff that is duplicate or should not
be there to start with. Platform-wise this is all over the place,
mainly omap, samsung, at91, imx and tegra."
Resolve trivial conflict in arch/arm/mach-omap2/clockdomains3xxx_data.c
* tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (67 commits)
ARM: clps711x: Remove the setting of the time
ARM: clps711x: Removed superfluous transform virt_to_bus and related functions
ARM: clps711x/p720t: Replace __initcall by .init_early call
ARM: S3C24XX: Remove unused GPIO definitions for Openmoko GTA02 board
ARM: S3C24XX: Remove unused GPIO definitions for port J
ARM: S3C24XX: Remove unused GPA, GPE, GPH bank GPIO aliases
ARM: S3C24XX: Convert the touchscreen setup code to common GPIO API
ARM: S3C24XX: Convert the PM code to gpiolib API
ARM: S3C24XX: Convert QT2410 board file to the gpiolib API
ARM: S3C24XX: Convert SMDK board file to the gpiolib API
ARM: S3C24XX: Free the backlight gpio requested in Mini2440 board code
ARM: imx: remove unused pdata from device macros
ARM: imx: Kconfig: Remove IMX_HAVE_PLATFORM_IMX_SSI from MACH_MX25_3DS
ARM: at91: fix new build errors
ARM: at91: add AIC5 support
ARM: at91: remove mach/irqs.h
ARM: at91: sparse irq support
ARM: at91: at91 based machines specify their own irq handler at run time
ARM: at91: remove static irq priorities for sam9x5
ARM: at91: add of irq priorities support
...
|
|
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>
|
|
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>
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-part2
Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
for 3.6. Mostly small infrastructure improvements, and preparation
for OMAP5 and AM33xx code.
Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
arch/arm/plat-omap/include/plat/omap_hwmod.h
|
|
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>
|
|
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>
|
|
Conflicts:
arch/arm/mach-omap2/dsp.c
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-pm
Reimplement the OMAP PRCM I/O chain code. Needed for I/O wakeups to
work correctly.
Conflicts:
arch/arm/mach-omap2/prm2xxx_3xxx.c
|
|
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>
|
|
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>
|
|
'control_clean_dspbridge_writes_cleanup_3.6', 'hwmod_soc_conditional_cleanup_3.6', 'mcbsp_clock_aliases_cleanup_3.6' and 'remove_clkdm_requirement_from_hwmod_3.6' into omap_cleanup_a_3.6
Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
_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>
|
|
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>
|
|
_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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes
From Paul Walmsley:
OMAP clock, powerdomain, clockdomain, and hwmod fixes intended for the
early v3.4-rc series. Also contains an HSMMC integration refinement
of an earlier hardware bug workaround.
* tag 'omap-fixes-a2-for-3.4rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending:
ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
ARM: OMAP2+: hwmod: Restore sysc after a reset
ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
ARM: OMAP3: clock data: fill in some missing clockdomains
ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
ARM: OMAP AM3517/3505: clock data: change EMAC clocks aliases
ARM: OMAP: clock: fix race in disable all clocks
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
ARM: OMAP3xxx: clock data: fix DPLL4 CLKSEL masks
ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attached
ARM: OMAP44xx: clockdomain data: correct the emu_sys_clkdm CLKTRCTRL data
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
power management changes for omap and imx
A significant part of the changes for these two platforms went into
power management, so they are split out into a separate branch.
* tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (65 commits)
ARM: imx6: remove __CPUINIT annotation from v7_invalidate_l1
ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
ARM: imx6q: resume PL310 only when CACHE_L2X0 defined
ARM: imx6q: build pm code only when CONFIG_PM selected
ARM: mx5: use generic irq chip pm interface for pm functions on
ARM: omap: pass minimal SoC/board data for UART from dt
arm/dts: Add minimal device tree support for omap2420 and omap2430
omap-serial: Add minimal device tree support
omap-serial: Use default clock speed (48Mhz) if not specified
omap-serial: Get rid of all pdev->id usage
ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at init
ARM: OMAP4: PRM: use PRCM interrupt handler
ARM: OMAP3: pm: use prcm chain handler
ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup pad
ARM: OMAP2+: mux: add support for PAD wakeup interrupts
ARM: OMAP: PRCM: add suspend prepare / finish support
ARM: OMAP: PRCM: add support for chain interrupt handler
ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrier
ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup
ARM: OMAP2+: mux: add wakeup-capable hwmod mux entries to dynamic list
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Non-critical bug fixes
Simple bug fixes that were not considered important enough for inclusion
into 3.2.
* tag 'fixes-non-critical' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
MAINTAINERS: update pxa and mmp
ARM: pxa: Include linux/export.h in balloon3.c
ARM: OMAP4: clock: Add CPU local timer clock node
ARM: OMAP4: hwmod: Don't wait for the idle status if modulemode is not supported
ARM: OMAP: AM3517/3505: fix crash on boot due to incorrect voltagedomain data
ARM: OMAP: hwmod data: fix the panic on Nokia RM-680 during boot
ARM: OMAP2+: DMA: Workaround for invalid destination position
ARM: OMAP2+: DMA: Workaround for invalid source position
|
|
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>
|
|
git://git.pwsan.com/linux-2.6 into prcm
Conflicts:
arch/arm/mach-omap2/Makefile
|
