Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be
retrieved by doing a clk_get with the corresponding device pointers or
device names.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Thara Gopinath <thara@ti.com>
Acked-by: Cousson, Benoit <b-cousson@ti.com>
[tony@atomide.com: fixed typo in email address]
Signed-off-by: Tony Lindgren <tony@atomide.com>
The registers are slightly different between v1 and v2 ip that
is available in omap4 and later for some timers.
Add support for v2 ip by mapping the interrupt related registers
separately and adding func_base for the functional registers.
Also disable dmtimer driver features on omap4 for now as
those need the hwmod conversion series to deal with enabling
the timers properly in omap_dm_timer_init.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Tested-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Now that all of the users of the OMAP_CHIP bitfield code have been converted
to use lists, the OMAP_CHIP code, data, and declarations can be removed.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.
Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
AM3517/3505 support, and for other review comments.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>
At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions. Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.
Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a
related patch that also applied to this patch - thanks Gražvydas.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three
functions. This allows some of them to be called multiple times: for
example, pwrdm_register_pwrdms() can be called once to register
powerdomains that are common to a group of SoCs, and once to register
powerdomains that are specific to a single SoC.
The appropriate order to call these functions - which is enforced
by the code - is:
1. pwrdm_register_platform_funcs()
2. pwrdm_register_pwrdms() (can be called multiple times)
3. pwrdm_complete_init()
Convert the OMAP2, 3, and 4 powerdomain init code to use these new
functions.
While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
At Tony's request, remove the omap_chip bitmasks from the clockdomain
and clockdomain dependency definitions. Instead, initialize
clockdomains based on one or more lists that are applicable to a
particular SoC family, variant, and silicon revision.
Tony Lindgren <tony@atomide.com> found a bug in a previous version of this
patch - thanks Tony.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions. This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are specific to a single SoC.
The appropriate order to call these functions - which is enforced
by the code - is:
1. clkdm_register_platform_funcs()
2. clkdm_register_clkdms() (can be called multiple times)
3. clkdm_register_autodeps() (optional; deprecated)
4. clkdm_complete_init()
Convert the OMAP2, 3, and 4 clockdomain init code to use these new
functions.
While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The OMAP_REVBITS_* macros are just used as otherwise meaningless
aliases for the numbers zero through five, so remove these macros.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
omap3_cpuinfo() contains essentially duplicated code from
omap3_check_revision(), just for the purpose of determining the chip ES level.
Set the cpu_rev char array pointer in omap3_check_revision() instead,
and drop the now-useless code from omap3_cpuinfo().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
Emit a warning to the console in omap3_check_revision() if that code
cannot determine what type of SoC the system is currently running on.
Remove some extra whitespace, remove some duplicate code, and
add an appropriate comment to a fallthrough case.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
of the OMAP2+ SoCs do in mach-omap2/cpu.c.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
The OMAP3505/AM3505 appears to be based on the same silicon as the
OMAP3517/AM3517, with some features disabled via eFuse bits. Follow
the same practice as OMAP3430 and identify these devices internally as
part of the OMAP3517/AM3517 family.
The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
as the OMAP3430, with some features disabled via eFuse bits. Identify
these devices internally as part of the OMAP3430 family.
Remove the old OMAP35XX_CLASS, which actually covered two very different
chip families. The OMAP3503/3515/3525/3530 chips will now be covered by
OMAP343X_CLASS, since the silicon appears to be identical. For the
OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.
Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
revision of this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
Add a missing array terminator to omap2430_usbhsotg_addrs[]. Without
this terminator, the omap_hwmod resource building code runs off the
end of the array, resulting in at least this error -- if not worse
behavior:
[ 0.578002] musb-omap2430: failed to claim resource 4
[ 0.583465] omap_device: musb-omap2430: build failed (-16)
[ 0.589294] Could not build omap_device for musb-omap2430 usb_otg_hs
This should have been part of commit
78183f3fdf ("omap_hwmod: use a null
structure record to terminate omap_hwmod_addr_space arrays") but was
evidently missed.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This patch updates the recently submitted
"Associate the HDMI clock together with LCDC1 on sh7372"
to V2 with the following change:
- Use lcdc1_device on AP4EVB to build properly.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The nfsservctl system call is now gone, so we should remove all
linkage for it.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit c03f007a8b (OMAP: PM:
omap_device: add system PM methods for PM domain handling) mistakenly
used SET_SYSTEM_SLEEP_PM_OPS() when trying to configure custom methods
for the PM domains noirq methods. Fix that by setting only the
suspend_noirq and resume_noirq methods with custom versions.
Note that all other PM domain methods (including the "normal"
suspend/resume methods) are populated using USE_PLATFORM_PM_SLEEP_OPS,
which configures them all to the default subsystem (platform_bus)
methods.
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Associate the HDMI clock together with LCDC1 on sh7372.
Without this patch Suspend-to-RAM hangs on the boards
AP4EVB and Mackerel. The code hangs in the LCDC driver
where the software is waiting forever for the hardware to
power down. By explicitly associating the HDMI clock with
LCDC1 we can make sure the HDMI clock is enabled using
Runtime PM whenever the driver is accessing the hardware.
This HDMI and LCDC1 dependency is documented in the sh7372
data sheet. Older kernels did work as expected but the
recently merged (3.1-rc)
794d78f drivers: sh: late disabling of clocks V2
introduced code to turn off clocks lacking software reference
which happens to include the HDMI clock that is needed by
LCDC1 to operate as expected.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Introduce them for each omap variant and just make them all call
omap2_init_common_infrastructure for now. Do this for each board-*.c
file except for board-generic and board-omap3beagle as they use
the same machine ID for multiple SoCs.
No functional changes.
Signed-off-by: Tony Lindgren <tony@atomide.com>
There's no need to call omap2_init_common_devices from init_early.
It no longer does anything else except reprogram the memory timings
for some boards, so it's better to do it later so we have a chance
to get console messages if something goes wrong.
Move it to happen after omap_serial_init gets called. And while
patching it anyways, rename it to omap_sdrc_init as suggested by
Benoit Cousson <b-cousson@ti.com>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
As noted by Grant Likely <grant.likely@secretlab.ca>, omap2+ Makefile unnecessarily
repeats entries for common device init code instead of using Kconfig symbol.
Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o
references can be removed once it has some Kconfig symbol to use.
Signed-off-by: Tony Lindgren <tony@atomide.com>
The oscillator that supplies GPT12_FCLK and WDT1_FCLK exists in the
WKUP powerdomain[1]. This resolves at least one boot-time warning:
omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.
1. _OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.1.x
Security Addendum Version K (SWPU119K)_ Figure 3-29. August 2010.
Fix the following compile warning:
arch/arm/mach-omap2/clock44xx_data.c: In function 'omap4xxx_clk_init':
arch/arm/mach-omap2/clock44xx_data.c:3371:6: warning: 'cpu_clkflg' may be used uninitialized in this function
The approach taken here is intended to work if omap4xxx_clk_init() is
converted into an initcall.
Thanks to Bjarne Steinsbo <bsteinsbo@gmail.com> for proposing another
approach.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Bjarne Steinsbo <bsteinsbo@gmail.com>
After commit 665d001338 ("OMAP2+: hwmod:
Follow the recommended PRCM module enable sequence"), device drivers
for OMAP IP blocks that do not use runtime PM can cause oopses or
kernel instability[1][2].
This is because those non-runtime PM drivers do not use the hwmod
code, which implements the correct IP block enable and disable
sequence.
Several options for dealing with this problem have been proposed:
1. Add a new field to the OMAP struct clk to mark clocks that are
currently used by non-runtime PM drivers. Modify the clock code to
use the old clockdomain sequence for these marked clocks. As
drivers are converted to use runtime PM, remove the annotation from
the clocks.
2. Similar to #1, but associate the flag with the struct omap_clk
instead.
3. Add IDLEST wait support to the OMAP4 clock code, similar to the way
it is implemented for OMAP2/3, and enable it in each struct clk
currently used by non-runtime PM drivers. As drivers are converted
to use runtime PM, remove the annotation from the clocks.
4. Do nothing; leave the problem to those responsible for the
unconverted drivers.
5. Re-enable clock-based clockdomain control in the OMAP4 clock code.
This would revert back to the behavior of Linux 3.0, simply with a
slightly longer module enable/disable latency.
Unfortunately, no approach seemed particularly good. Options 1
through 3 seemed unwise due to the following reasons:
A. The OMAP struct clks are intended primarily to describe hardware
clock nodes, and the intention is that no driver-specific data
should be stored there (applies to #1)
B. The resulting patch would have been quite large for the -rc series
(applies to #1, #2, #3)
C. The patch would have been a new, yet temporary hack; and similar fixes
have drawn negative comments in the recent past (see for example [3])
Option 4 is undesirable because commit
665d001338 ("OMAP2+: hwmod: Follow the
recommended PRCM module enable sequence") has resulted in a less
stable kernel; and kernel stability is more important than OMAP4 power
management.
Option 5 is the approach taken in this patch. This seemed to be the
least intrusive approach for 3.1-rc.
The approach in this patch was originally proposed by Ohad Ben-Cohen
<ohad@wizery.com>. I'm simply writing the commit message and passing
it along.
...
Thanks to Luciano Coelho <coelho@ti.com> for reporting the problem.
Thanks to Ohad Ben-Cohen <ohad@wizery.com> for tracking the problem
down, generating a temporary workaround, and proposing a patch to deal
with the problem. Thanks to Rajendra Nayak <rnayak@ti.com> for
proposing another patch to deal with the problem. Thanks to Felipe
Balbi <balbi@ti.com> for comments.
1. Coelho, Luciano <coelho@ti.com>. _Re: Oops on ehci_hcd when
booting 3.0.0-rc2 on panda_. Tue, 09 Aug 2011 14:26:08 +0300.
Posted to the <linux-omap@vger.kernel.org> mailing list. Available
from (among others)
http://www.spinics.net/linux/lists/linux-omap/msg55213.html
2. Munegowda, Keshava <keshava_mgowda@ti.com>. _Re: Oops on ehci_hcd
when booting 3.0.0-rc2 on panda_. Thu, 11 Aug 2011 13:51:05 +0530.
Posted to the <linux-omap@vger.kernel.org> mailing list. Available
from (among others)
http://www.spinics.net/linux/lists/linux-omap/msg55371.html
3. King, Russell <linux@arm.linux.org.uk>. _Re: [PATCH 5/8] OMAP4:
PM: TEMP: Prevent l3init from idling/force sleep_. Thu, 23 Jun
2011 16:22:49 +0100. Posted to the <linux-omap@vger.kernel.org>
mailing list. Available from (among others)
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51392.html
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Luciano Coelho <coelho@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
While using clockdomain force wakeup method, not waiting for powerdomain
to be effectively ON may end up locking the clockdomain FSM until a
next wakeup event occurs.
One such issue was seen on OMAP4430, where L4_PER was periodically
getting stuck in in-transition state when transitioning from from OSWR to ON.
This issue was reported and investigated by Patrick Titiano <p-titiano@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Patrick Titiano <p-titiano@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[paul@pwsan.com: updated to apply; added transition wait on clkdm_deny_idle();
remove two superfluous pwrdm_wait_transition() calls]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Program all powerdomain target state as ON; this is to prevent domains
from hitting low power states (if bootloader has target states set to
something other than ON) and potentially even losing context while PM
is not fully initialized, which can cause the system to crash. The PM
late init code can then program the desired target state for all the
power domains.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: dropped comment typo hunk; fixed comment indent and moved
to kerneldoc; moved code to pwrdm_init(); changed pwrdm_init() argument name
to prevent clash; cleaned up patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Instead of setting up a match interrupt for 'current_time + delta'
on ->set_next_event(), program timer 0 to count down from 'delta - 1'
and trigger an interrupt when it reaches zero.
Signed-off-by: Lennert Buytenhek <buytenh@laptop.org>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Currently, arch-mmp/time.c uses timer 0 both as a clocksource timer
and as a clockevent timer, the latter by setting up a comparator
interrupt to match on 'current_time + delta'. This is problematic
if delta is small enough, as that can lead to 'current_time + delta'
already being in the past when comparator setup has finished, leading
to the requested event not triggering.
As there is also a silicon issue that requires stopping a timer's
counter while writing to one of its match registers, we'll switch to
using two separate timers -- timer 0 as clockevent timer, which we'll
start and stop on every invocation of ->set_next_event(), and timer 1
as clocksource timer, which will be free-running.
This first patch enables timer 1 on boot, so that we can use it as
clocksource timer.
Signed-off-by: Lennert Buytenhek <buytenh@laptop.org>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
Move definitions from mfp-gplugd.h to mfp-pxa168.h as they aren't
gplugD specific.
Signed-off-by: Tanmay Upadhyay <tanmay.upadhyay@einfochips.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
The PCI nanoengine driver in the SA1100 machine probably has not
been building for some time. It probably dragged hardware.h
in implicitly and now it doesn't anymore. After this an SA1100
build selecting all system variants will build successfully.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the
timer stops counting once overflow occurs as it was not set in autoreload mode.
This results into timekeeping failure: for example, 'sleep 1' at the shell after
the timer counter overflow would hang.
This patch sets up autoreload when starting the clocksource timer which fixes
the above issue.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Since 7203f8a48b (arm: mach-omap2: remove
NULL board_mux from board files) NULL board_mux is defined in mux.h.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Use kstrdup rather than duplicating its implementation
The semantic patch that makes this output is available
in scripts/coccinelle/api/kstrdup.cocci.
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The pointer "va" returned from "phys_to_virt(pa)" is never used in
"sgtable_fill_kmalloc()".So,it is safe to remove this set-but-unused variable.
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add missing definitions for the AM3505/3517 UART4 such
as DMAs, INTs and base address.
Signed-of-by: Raphael Assenat <raph@8d.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This has now been well tested, and several platforms are now selecting
this directly. It's time to drop its experimental status.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Builds for multi-OMAP2 (e.g., OMAP2420 with OMAP2430) with
CONFIG_ARCH_OMAP4=n fail with the following errors:
arch/arm/mach-omap2/built-in.o: In function `_enable_module':
arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to `omap4_cminst_module_enable'
arch/arm/mach-omap2/built-in.o: In function `_disable_module':
arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to `omap4_cminst_module_disable'
arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable':
arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to `omap4_cminst_wait_module_idle'
This is probably due to the preprocessor directives in
arch/arm/plat-omap/include/plat/cpu.h that convert some cpu_is_omap*()
expressions from preprocessor directives into something that is only
resolvable during runtime, if multiple OMAP2 build targets are
selected.
Thanks to Tony Lindgren <tony@atomide.com> for reporting.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit b22f954 (OMAP4: Move common twl6030 configuration to twl-common)
caused compile failures for code for OMAP arch which is not selected by
the config.
Fixes issues like:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to `omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to `omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to `omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to `omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to `omap4430_phy_suspend'
Fix the problem by moving the code to ifdef sections for omap3 and omap4.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
With the UM_SIGNAL alignment fault mode, no siginfo structure is
passed to userspace.
POSIX specifies how siginfo_t should be populated for alignment
faults, so this patch does just that:
* si_signo = SIGBUS
* si_code = BUS_ADRALN
* si_addr = misaligned data address at which access was attempted
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Currently, it's possible to set the kernel to ignore alignment
faults when changing the alignment fault handling mode at runtime
via /proc/sys/alignment, even though this is undesirable on ARMv6
and above, where it can result in infinite spins where an un-fixed-
up instruction repeatedly faults.
In addition, the kernel clobbers any alignment mode specified on
the command-line if running on ARMv6 or above.
This patch factors out the necessary safety check into a couple of
new helper functions, and checks and modifies the fault handling
mode as appropriate on boot and on writes to /proc/cpu/alignment.
Prior to ARMv6, the behaviour is unchanged.
For ARMv6 and above, the behaviour changes as follows:
* Attempting to ignore faults on ARMv6 results in the mode being
forced to UM_FIXUP instead. A warning is printed if this
happened as a result of a write to /proc/cpu/alignment. The
user's UM_WARN bit (if present) is still honoured.
* An alignment= argument from the kernel command-line is now
honoured, except that the kernel will modify the specified mode
as described above. This is allows modes such as UM_SIGNAL and
UM_WARN to be active immediately from boot, which is useful for
debugging purposes.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
poison_init_mem() used a loop of:
while ((count = count - 4))
which has 2 problems - an off by one error so that we do one less word
than we should, and the other is that if count == 0 then we loop forever
and poison too much. On a platform with HAVE_TCM=y but nothing in the
TCM's, this caused corruption and the platform failed to boot.
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The file mm/proc-arm946.S contains a typo and is missing a structure
member in __arm946_proc_info. The former prevents compilation
and the latter causes problems during boot. It is likely this
file was manually copied from a similar file and not tested, then
later updates to the *_proc_info structures missed this file.
This patch will apply (with offset) with or without the
recent macro unification work that has been done in this directory.
This was verified against linux-next/stable last week.
See arm-linux-kernel thread:
http://lists.arm.linux.org.uk/lurker/message/20110718.103237.0106d468.en.html
Signed-off-by: Brian S. Julin <bri@abrij.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit fad107086d fixed the wrong test for MX51
as the MX51 addresses are wrong for MX50 and MX53 but now it's MX51 only,
UART_PADDR is not defined anymore when building for MX50/MX53.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Steev Klimaszewski <steev@genesi-usa.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
irq_to_gpio() is being called on a GPIO so change to using
gpio_to_irq() instead.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
For marketing reasons the part will be called WM8996. In order to avoid
user confusion rename the driver to reflect this.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Tarun Kanti DebBarma