Convert all OMAP3 specific platform files to use COMMON clk
and keep all the changes under the CONFIG_COMMON_CLK macro check
so it does not break any existing code. At a later point switch
to COMMON clk and get rid of all old/legacy code.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Mike Turquette <mturquette@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Pull KVM fix from Marcelo Tosatti:
"A correction for user triggerable oops"
* git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461)
This pull request contains those missing clkdev entries which are needed
to boot that platform.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQoT87AAoJEDqPOy9afJhJRyYP/0SVLiDlDMZ6bm3UqzKsqY4V
QhlSZQAJo/7FFRATeB7hGVAwayYSnzOcXMPvViCWGPe/30cva+IN7HzUbqvMHOfL
vBfSBIMZT9nqC74gQe8QytKuGG1Aysw4bzhDxLiePxB7yEtMMJ22yoabVQfQSsuS
U09pJ1jfAwNkLFLOwdDGgmx+xajPp3VVQRUC0R5mE/S/MowC1KPjRPZJZZwUPrjf
WXKKXYd2tv7d6IoZ9kPbgu5zsEqdF5a+GHkTuYlJw3Zk1VEOZuFLVAmskyyX9hvi
t6609gsyxch+nxFaz0BYV1Cf/fCcvLgL/oRAGbtspiiJL7IOwBbV7ojfNHd+3Pju
CNh0B1aRE0QrIv5cvcvdOA9VtLo1yyOjWpo5o2iwcSiD0d+txyztb5p16tTausSt
7LRxNdvt7aT9SsxtGLMa/PLlyRO+HSW8BKUo3Y84ZiwxJGGyIqv07tQd0jhlwXzv
OZtFe63f7MeWc/MwuAFBkSQM7UGMtHpyWuZJ2EGwnHCPssq1D7yzTWLLI3n3fgin
G1kIQklQwS+SrkjQGzZyYo436Dt3uJJ4mmCsrHypjfg6dUEYphkuucwJs3aiWNNX
YzIBAKKr9rQWKaYx7vqYe/0Jg3jxnGpAnYqurI1jCJJ0xQhQ5BMksdMehUclujRw
VRvnAZn5oKQVUGPnpVjE
=VC2a
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux
Pull ux500 clk fixes from Mike Turquette:
"Missing clkdev entries are causing regressions on the U8500 platform.
This pull request contains those missing clkdev entries which are
needed to boot that platform."
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux:
clk: ux500: Register slimbus clock lookups for u8500
clk: ux500: Update rtc clock lookup for u8500
clk: ux500: Register msp clock lookups for u8500
clk: ux500: Register ssp clock lookups for u8500
clk: ux500: Register i2c clock lookups for u8500
Pull menuconfig portability fix from Michal Marek:
"Here is a fix for v3.7 that makes menuconfig compile again on systems
whose C library is lacking CIRCLEQ_* macros. I thought I sent it
earlier, but apparently I did not."
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
menuconfig: Replace CIRCLEQ by list_head-style lists.
Pull LED fix from Bryan Wu.
* 'fixes-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
ledtrig-cpu: kill useless mutex to fix sleep in atomic context
Pull futex fix from Thomas Gleixner:
"Single fix for a long standing futex race when taking over a futex
whose owner died. You can end up with two owners, which violates
quite some rules."
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
futex: Handle futex_pi OWNER_DIED take over correctly
The current code holds on to this list until nfsd is shut down, but it's
never touched once the grace period ends. Release that memory back into
the wild when the grace period ends.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Remove the cl_recdir field from the nfs4_client struct. Instead, just
compute it on the fly when and if it's needed, which is now only when
the legacy client tracking code is in effect.
The error handling in the legacy client tracker is also changed to
handle the case where md5 is unavailable. In that case, we'll warn
the admin with a KERN_ERR message and disable the client tracking.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
The current code requires that we md5 hash the name in order to store
the client in the confirmed and unconfirmed trees. Change it instead
to store the clients in a pair of rbtrees, and simply compare the
cl_names directly instead of hashing them. This also necessitates that
we add a new flag to the clp->cl_flags field to indicate which tree
the client is currently in.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
When nfsd starts, the legacy reboot recovery code creates a tracking
struct for each directory in the v4recoverydir. When the grace period
ends, it basically does a "readdir" on the directory again, and matches
each dentry in there to an existing client id to see if it should be
removed or not. If the matching client doesn't exist, or hasn't
reclaimed its state then it will remove that dentry.
This is pretty inefficient since it involves doing a lot of hash-bucket
searching. It also means that we have to keep relying on being able to
search for a nfs4_client by md5 hashed cl_recdir name.
Instead, add a pointer to the nfs4_client that indicates the association
between the nfs4_client_reclaim and nfs4_client. When a reclaim operation
comes in, we set the pointer to make that association. On gracedone, the
legacy client tracker will keep the recdir around iff:
1/ there is a reclaim record for the directory
...and...
2/ there's an association between the reclaim record and a client record
-- that is, a create or check operation was performed on the client that
matches that directory.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Later callers will need to make changes to the record.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
We'll need to be able to call this from nfs4recover.c eventually.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Currently, it takes a client pointer, but later we're going to need to
search for these records without knowing whether a matching client even
exists.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Let's shoot for removing the nfsdcld upcall in 3.10. Most likely,
no one is actually using it so I don't expect this warning to
fire often (except maybe on misconfigured systems).
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
The usermodehelper upcall program can then decide to use this info as
a (one-way) transition mechanism to the new scheme. When a "check"
upcall occurs and the client doesn't exist in the database, we can
look to see whether the directory exists. If it does, then we'd add
the client to the database, remove the legacy recdir, and return
success to the kernel to allow the recovery to proceed.
For gracedone, we simply pass the v4recovery "topdir" so that the
upcall can clean it out prior to returning to the kernel.
A module parm is also added to disable the legacy conversion if
the admin chooses.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
First, try to use the new usermodehelper upcall. It should succeed or
fail quickly, so there's little cost to doing so.
If it fails, and the legacy tracking dir exists, use that. If it
doesn't exist then fall back to using nfsdcld.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Add a new client tracker upcall type that uses call_usermodehelper to
call out to a program. This seems to be the preferred method of
calling out to usermode these days for seldom-called upcalls. It's
simple and doesn't require a running daemon, so it should "just work"
as long as the binary is installed.
The client tracking exit operation is also changed to check for a
NULL pointer before running. The UMH upcall doesn't need to do anything
at module teardown time.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
These changes provide a generic gpmc timing calculation method,
migrates existing peripherals that makes use of custom gpmc timing
calculation method to use the new generic one.
Generic routine has been verified for onenand async timing calculation
on omap3evm (with a local change to add onenand support). Generic
timing calculation method were verified for other peripherals by
simulation. Generic method has to be verified on peripherals supported
in mainline.
Just use BUG_ON() instead of constructions such as:
if (...)
BUG()
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
@@
- if (e) BUG();
+ BUG_ON(e);
// </smpl>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
On hosts without the XSAVE support unprivileged local user can trigger
oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
ioctl.
invalid opcode: 0000 [#2] SMP
Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
...
Pid: 24935, comm: zoog_kvm_monito Tainted: G D 3.2.0-3-686-pae
EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
task.ti=d7c62000)
Stack:
00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000
ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0
c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80
Call Trace:
[<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
...
[<c12bfb44>] ? syscall_call+0x7/0xb
Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
0068:d7c63e70
QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
X86_FEATURE_XSAVE even on hosts that do not support it, might be
susceptible to this attack from inside the guest as well.
Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Hi Greg,
Here's some xHCI bug fixes. There's nothing major in here that can't
wait for 3.8. The NULL pointer deref that commit 68e5254 fixes hasn't
ever been reported in the three years that the xHCI driver has been
available, so it can wait a few more weeks.
There's two quirk updates, one for Fresco Logic (commit bba18e3) and one
for xHCI hosts with the TI redriver (commit b0e4e60). Commit 4525c0a
makes the xHCI driver work correctly on the SiBridge xHCI host (and
perhaps other 1.0 xHCI host controllers). Commit 392a07a fixes a bug in
the Intel Panther Point xHCI host bandwidth checking checking.
Commits 2611bd1 and 77b8476 are trivial cleanup patches.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQoWZQAAoJEBMGWMLi1Gc53l8P/R05/ZTz+2VsdiotzqOnvJVJ
b3h2ja4YLy5rtcU5nyn8yEISJVKVowt4w+J9lEVWj8ZtbLptAvQlUjM+2HCdgrTr
RF5p4Y+5Wa0BHosqya4YPkQFu2ZMEDqgkpbfNU4q0hjrJEwUiB8XNfN2CqoO9RNk
wQhEISQzhL2bmlgoKejlaU+csW4F1RZ1778SIWS/mj6zqtwc5JBn5J8o/DavJehk
b2BGCRTKTtVnnP+N5LcWuJQg1tdi48ngigqo0VOqxjFTZ/w5YMLDZfXOBy/91lTI
8i6hKwU1/LH5hPQf+e8K9H3TbiVUg3TAe7UovstPd9UrVS0xbNgKydjhP0y6/Ozy
4TnmaQK4IQEGUVwzYLwIKCRrEZ32CNPIzm+ZU82MsMJH2rB0pP4yp1Gcu/IXTQJg
wAyRNeheKiz6HqYeWE5ZuGK8h8Sodd+LJQeMl+ma/mlx6LvI/wpas8U13qTyOXsV
E2UzqP4LrnMWtF8sEVnHa85hLvpdYLJDHMGrHHCb2OIgBuVmmf+U+xq7bZBIdeHZ
iF66czS3ltdgXzimZfHpdTU/i12j3wGQ+si+b5d5GjjgBPJsQTecZD0GtOX4kQ5d
3roFyW8JY7IEVT8dNRtJsi5sG+DOmtFWycCxA0BicTqa1VVahQoBCQY6UYtce5yD
b0F5ZWeaGmee9zXSgpWD
=aiNz
-----END PGP SIGNATURE-----
Merge tag 'for-usb-next-2012-11-12' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next
XHCI patches from Sarah:
"xHCI patches for 3.8
Hi Greg,
Here's some xHCI bug fixes. There's nothing major in here that can't
wait for 3.8. The NULL pointer deref that commit 68e5254 fixes hasn't
ever been reported in the three years that the xHCI driver has been
available, so it can wait a few more weeks.
There's two quirk updates, one for Fresco Logic (commit bba18e3) and one
for xHCI hosts with the TI redriver (commit b0e4e60). Commit 4525c0a
makes the xHCI driver work correctly on the SiBridge xHCI host (and
perhaps other 1.0 xHCI host controllers). Commit 392a07a fixes a bug in
the Intel Panther Point xHCI host bandwidth checking checking.
Commits 2611bd1 and 77b8476 are trivial cleanup patches.
Sarah Sharp"
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function calls clk_disable() before
calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
omap_hwmod_enable() to after the call to clk_set_parent() in
omap_dm_timer_init_one().
The function omap_hwmod_setup_one() will enable the timers functional clock
and therefore increment the use-count of the functional clock to 1.
clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
clk_disable() before calling clk_set_parent() to decrement the use-count.
Hence, avoid these extra calls to disable and enable the functional clock by
moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
clk_set_parent().
We can also remove the delay from the __omap_dm_timer_set_source() function
because enabling the clock will now be handled via the HWMOD framework by
calling omap_hwmod_setup_one(). Therefore, by moving the calls to
omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
clk_set_parent().
It should be safe to move these hwmod calls to later in the
omap_dm_timer_init_one() because other calls to the hwmod layer that occur
before are just requesting resource information.
Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
with the following configurations:
1. CONFIG_OMAP_32K_TIMER=y
2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer"
3. CONFIG_OMAP_32K_TIMER not set
4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer"
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
2 and 10 need this function and for OMAP5 all timers need this function.
Please note that the interrupt disable function has been written so that it
can be used by all OMAP devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The OMAP DMTIMERs can generate an interrupt when the timer counter value
matches the value stored in the timer's match register. When using this
feature spurious interrupts were seen, because the compare logic is being
enabled before the match value is loaded and according to the documentation
the match value must be loaded before the compare logic is enable.
The reset value for the timer counter and match registers is 0 and hence,
by enabling the compare logic before the actual match value is loaded a
spurious interrupt can be generated as the reset values match.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence it's
context will not be lost. Users should take care to service all interrupts
before disabling the timer.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.
For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.
Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d080 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.
For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.
For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the "timer->posted" variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Since commit edc88ceb0 (ARM: be really quiet when building with 'make -s') the
following output is generated when building a kernel for ARM:
echo ' Kernel: arch/arm/boot/Image is ready'
Kernel: arch/arm/boot/Image is ready
Building modules, stage 2.
echo ' Kernel: arch/arm/boot/zImage is ready'
Kernel: arch/arm/boot/zImage is ready
As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
'@$(kecho)'.
Make this change so no more unwanted 'echo' messages are displayed.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC. This signal
controls the secure-mode operation of the PMIC. If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.
For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.
To fix, ensure the signal is properly mux'd as output when TWL is
intialized.
This fix is required when using recent versions of u-boot (>= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Remove the platform static mapping code for uart and use the common
debug_ll_io_init function.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Remove duplicated include.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This first patch serie start the cleanup of the header in mach
by moving all the platform data to include/linux/platform_data
and move the board header and drivers header next to them
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQmQMyAAoJEOrjwV5ZMRf2N8kP/1J2DI26zhNWGIdiTPFX/HXG
o03lvElDKDDyNtC87gU2DnYkOdjFVRpagZxv089whDs4Lt22A8ClaxEFca9K1oPg
XO0NtuHbTL3wGlPLJH4C90bpQWY4FyIQLMfPaMeifrP1OpRkeSWAYKfFUB/wOtRC
KWNl+WmpBt9JN9H1RIezYxpRteC+wUBKpYVZkRdT3OkQ4/oMqDIWzZqkMCTKy+Bb
Ucs9ZFqkJ/5fSGYjHLG34VpbepFKgCqeDVugz2v+7SHvIkl0/XbRhGOdxJek54GD
0OW8Gg5Utw47YQ1uYDR3IM00cod41/l9NYMKZm/DIEUdvNP3Mp+/X0Knehov+O+7
7Xs8eSzBHE0mRAx2as71av08PNptNVAcJh/UAO8PWE5yLGivGrp8kQWzJItnl2ma
8GmIK26bmMAqGuR+wANrT/pCCW5kxALE8L1JnCMzjhv5TvKE88mjUZuVmNnZGCdY
SE/hotD2c2asZ15zv52wrGGpOALW6ZaQdlRafuDli1/yHeJ1uPOWec7NKnzytDpL
A0r22RDyvqR7N2hunFu2aO757ojAsIWS8qfF2Yztr0UaE6rC+aoYKBwTfzvC5yhh
gaurkH8jCUJ9EHw+GBs1pZQK9wWaK7MrlNj7/mVZ1iXErWCHZYcYNbxlx/xAFzUv
IoHsmg6lL5By3p3nvElG
=c5hx
-----END PGP SIGNATURE-----
Merge tag 'for-3.8-at91_header_clean' of git://github.com/at91linux/linux-at91 into next/headers
From Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
arm: at91: mach header cleanup
This first patch serie start the cleanup of the header in mach
by moving all the platform data to include/linux/platform_data
and move the board header and drivers header next to them
* tag 'for-3.8-at91_header_clean' of git://github.com/at91linux/linux-at91:
arm: at91: move at91rm9200 rtc header in drivers/rtc
arm: at91: move reset controller header to arm/arm/mach-at91
arm: at91: move pit define to the driver
arm: at91: move at91_shdwc.h to arch/arm/mach-at91
arm: at91: move board header to arch/arm/mach-at91
arn: at91: move at91_tc.h to arch/arm/mach-at91
arm: at91 move at91_aic.h to arch/arm/mach-at91
arm: at91 move board.h to arch/arm/mach-at91
arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
arm: at91: drop machine defconfig
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
introduced by the earlier clean-up and clean up few more
things for enabling multiplatform support.
The multiplatform kernel has been booted on omaps on
top of this branch with the work-in-progress patches
applied manually.
We cannot yet enable the multiplatform support though.
We still need the common clock framework patches, some
solution for dma-omap.h, and serial-omap.h moved before
we can enable it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQmaU8AAoJEBvUPslcq6VzbfcQAOEIQpv2zQz68euDDkCndBcG
rVjDIyAM/wgbxgdqK66FQvCZefQhSUBimBmjqagVwRh/2lIDZOfhIS98N5eMbJEQ
3UJUuOAPJQLmwR4zyKgbi/hdWZDEjnYvMJEmVSeSpXSmRO844ggtc9F2K22ouQ5m
CJ0WZE6p55v25bMLDETudLlzCfhrSGiApwV09IUxFAd9va7UeXibYt83oh1A6joo
U0i6sGbMgxR3uLi/7q7Wlm6dbCVU5N8+EtJ2L/tkoAQDHb+iLmkC8n3N3KPBkrEu
KpS7o3zuCDS3X6m8bD4w1j8WVeNX3ERA9avWMSBpfTQQcj0OvTPZixe7KC9WwT/4
nI0bAKQ/JWmFV+Ibo5jtVS151XeEG6ggap6aa+F3wYpkORY+jWcX0djW+1NDwScB
nGDcRI1n15jogoJJC9SB5wFW7K3wgi6Sb3Mo7nvNVvvQcHXpxiadujPP+tiHm7mn
mDoMJYHa0oI9jlWPSrAC5E8rfSR1NYRv7A5BLkakGXErEED+MByJ84PR3q4xDivx
B58HgsXTbJkQQug6o5yFK2vCKQW1Vsi0cdKrm3kY1JuLLfNMXbPFpAihxoLZ9Rp5
oDTdPpslgdEMMvg346q7XLFYiG9F5Zoz60MaUpYBa5EsmA16WB2ZT0t5bLIpxglx
0duNMqDZYsBrKc3aYjw3
=8Nz+
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/headers
From Tony Lindgren <tony@atomide.com>:
These changes deal with the issues of relative includes
introduced by the earlier clean-up and clean up few more
things for enabling multiplatform support.
The multiplatform kernel has been booted on omaps on
top of this branch with the work-in-progress patches
applied manually.
We cannot yet enable the multiplatform support though.
We still need the common clock framework patches, some
solution for dma-omap.h, and serial-omap.h moved before
we can enable it.
* tag 'omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP: Remove omap_init_consistent_dma_size()
ARM: OMAP: Remove NEED_MACH_GPIO_H
ARM: OMAP: Remove unnecessary mach and plat includes
ARM: OMAP2+: Fix relative includes for serial.h
ARM: OMAP: Fix relative includes for fpga.h
ARM: OMAP1: Remove relative includes
ARM: OMAP: Remove cpu_is_omap usage from plat-omap/dma.c
ARM: OMAP: Fix relative includes for debug-devices.h
ARM: OMAP: Remove plat-omap/common.h
ARM: OMAP: Move omap-pm-noop.c local to mach-omap2
ARM: OMAP: Fix relative includes for shared i2c.h file
ARM: OMAP: Make plat-omap/i2c.c port checks local
ARM: OMAP: Move omap2+ specific parts of sram.c to mach-omap2
ARM: OMAP: Move omap1 specific code to local sram.c
ARM: OMAP: Introduce common omap_map_sram() and omap_sram_reset()
ARM: OMAP: Split sram.h to local headers and minimal shared header
ARM: OMAP1: usb: fix sparse warnings
Conflicts:
arch/arm/mach-omap2/cm33xx.c
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes the following error:
CC arch/arm/mach-omap2/cm_common.o
arch/arm/mach-omap2/cm_common.c: In function ‘cm_register’:
arch/arm/mach-omap2/cm_common.c:42:11: error: ‘EINVAL’ undeclared (first use in this function)
arch/arm/mach-omap2/cm_common.c:42:11: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/mach-omap2/cm_common.c:45:11: error: ‘EEXIST’ undeclared (first use in this function)
arch/arm/mach-omap2/cm_common.c: In function ‘cm_unregister’:
arch/arm/mach-omap2/cm_common.c:66:11: error: ‘EINVAL’ undeclared (first use in this function)
make[1]: *** [arch/arm/mach-omap2/cm_common.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Kevin Hilman and Paul Walmsley.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQmXAHAAoJEBvUPslcq6Vz3GUP/RRDpRcsJUh0wQMA+MYDdPJf
dVcYYczUPn7LCZEXsWVHiwOA0BxR+TQ1N7trUyGkj1cgGo3ImUatDHT9Czy1zZQs
8fpb+2kkNoxhEeWkxYT6LZZ+RuwGfo6mruJSCX1ZCf8oblW8QqduNLjCJGViEc/J
WFuuFb+ucSvqJWsD5L3Bma4/rkYhAx20MjoLWEh69WUUdVip1/YTZCT9ui7wRFin
afvq2USSEacQBaPbY+rMOOJU13YK9pNLU5+kgiRyoQ63BIoI4Wl1smDa0NoyYoFO
S8cIekRtXZQTUCp+r4IDz5ZTJ24Lu7ywMaawrQlHuKShxLaPTHJZAKSxcCg0pEdc
gDj1FJ65PczSMryos6WR6M0kqInfJK8SGlGVUe9y3wV5kFKOrc/G3e1Vi8/xbBFn
J9dkriQJ5Xf0w4VpfY4yy1TAQAWnHPunucFUMLKUXWwAnk4eSxRgz/zZBvj7xbey
6oNre4W/fHXnF8YE1wLIsrqQJq9pOIQc9jz22/knjF0jjhQU1alFyJ6MhyINIH0o
gJv1rO+VWfhsG/ECYd01E7ChG+9bATWjJpPHHB6brC24VLNgcDUlrJurvuGhNU8d
5P+/6OKenBj+hHWuiWIpFY+jIkG9NRcq2QIPEkFVIvfDHZ34H5FTB89d1Kw3hLSX
/0h4NvAA4aK8oJuItOhI
=pyxl
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v3.7-rc4/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren <tony@atomide.com>:
Minor OMAP PM and hwmod fixes for v3.7-rc series via
Kevin Hilman and Paul Walmsley.
* tag 'omap-for-v3.7-rc4/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP4: PM: fix regulator name for VDD_MPU
ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init
ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP
ARM: OMAP2+: PM: add missing newline to VC warning message
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARCH_CNS3XXX already selects MIGHT_HAVE_PCI, so boards don't have to
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The debug-leds driver should not rely on hard coded macro for
the iomem size but use the resource size instead.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
From Simon Horman <horms@verge.net.au>:
* This pull-request is based on the boards branch of the rensas tree
which I have sent a pull-request for. The boards branch is in
turn based on the soc branch. The reason for the soc2 -> boards -> soc
branch progression is to satisfy dependencies of patches in
the boards and soc branches.
* 'soc2' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: sh7372: sh7372_fsiXck_clk become non-global
ARM: shmobile: sh7372: remove fsidivx clock
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* This pull request is based on a merge of
a) The renesas/boards branch of the arm-soc tree
b) The soc branch of the renesas tree,
which I have sent a separate pull requst for
* "sh: clkfwk: add sh_clk_fsidiv_register()" is a driver patch
which is a dependency of
- ARM: shmobile: sh7372: use sh_clk_fsidiv_register() for FSI-DIV clocks
- ARM: shmobile: r8a7740: add FSI-DVI clocks
I have spoken to the driver maintainer, Paul Mundt, and he has indicated
that he thinks it is best to merge all in one go and acked the patch for
inclusion in this pull-request.
* The following patches
- ARM: shmobile: use FSI driver's audio clock on ap4evb
- ARM: shmobile: use FSI driver's audio clock on mackerel
- ARM: shmobile: use FSI driver's audio clock on armadillo800eva
Have a compile-time dependency on the following patch which is present in
the for-next branch of Mark Brown's sound tree on kernel.org
- ASoC: fsi: add master clock control functions
(ab6f6d8521)
* 'boards' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: use FSI driver's audio clock on ap4evb
ARM: shmobile: use FSI driver's audio clock on mackerel
ARM: shmobile: use FSI driver's audio clock on armadillo800eva
ARM: shmobile: mackerel: enable DMAEngine on USB Host
ARM: shmobile: marzen: add USB OHCI driver support
ARM: shmobile: marzen: add USB EHCI driver support
ARM: shmobile: marzen: add USB phy support
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
