Reorganize the hwmod data to declare the IP blocks first and the
interconnects second.  This allows us to remove the forward
declarations, which this patch also does. Saves some lines of source
data.  While here, take the opportunity to synchronize the order of
the OMAP44xx hwmod data with the autogenerator output -- it's slightly
different due to past mismerges -- and fix a few minor typos and
whitespace problems in the files.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.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: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Register interconnect links between IP blocks, rather than the IP
blocks themselves.  (The IP blocks will be registered as a side-effect
of registering the links.)

The objective is to reduce the number of lines of static data and
facilitate the sharing of IP block data between different SoCs.  These
objectives come at the penalty of increased boot time due to increased
computation.

While here, fix a few whitespace problems and inaccurate variable names.
Signed-off-by: NPaul 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: NPaul 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: NPaul 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: NPaul 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: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Extend the OCP_* register offsets in the struct
omap_hwmod_class_sysconfig to 32 bits.  This is required to add the
OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
bits.

Another possible solution may be to simply add a single 16 bit offset
field in this structure, and to add code to factor that offset into
all OCP_* register accesses.  This would save some memory, since
almost no modules need 32 bit offsets.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Some hwmods were commented out from the OMAP4 data, under the theory
that they shouldn't be added until drivers were ready.  But part of
the utility of the hwmod code is that it can reset and properly
initialize IP blocks that have no drivers associated with them.
Rather than commenting the links in the future hwmod data conversion
patches, discussing this with Benoit, it seems best to simply
uncomment them now.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

One of the OMAP4 links was missing OCP_USER flags, since it was only
used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
Future patches will switch the hwmod code and data to register
interfaces, rather than hwmods, and it will be mandatory for all
interfaces to have at least one user bit set.  This patch resolves the
issue by adding OCP_USER_DSP and marking the DSP-IVA interface
appropriately.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

Commit 407a6888 ("OMAP4: hwmod data:
Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a
hwmod for the bandgap die temperature sensor IP block.  This IP block
has no interconnect port or firewall region, nor does it have an
independent register space or OCP control registers.  Its registers
are embedded in the System Control Module (SCM) IP block.  So it
appears that the bandgap device should be created by the SCM driver.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

GPTIMER12 is attached to the L4 SEC interconnect, not directly to L4 WKUP.
Add the L4 SEC interconnect and attach GPTIMER12 to it.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the
OMAP3430 ES1 DSS hwmod.  Since the hwmod code and data is being modified
to register interfaces rather than hwmods, this would result in the DSS hwmod
not being registered correctly on OMAP3430ES1.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Commit a52e2ab6 ("ARM: OMAP3: hwmod
data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1")
didn't link the MMC hwmods to the interconnects correctly.  Future
patches will register hwmods by interface, so if this is not fixed,
the MMC IP blocks won't be registered.  Update the interface data
records to point to the correct IP blocks.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Some of the 2xxx and 3xxx hwmod data files use the old naming style
for hwmods, ending in a "_hwmod".  These names are used by the OMAP
integration code to map hwmods to platform_devices, so they need to be
consistent, or the platform_devices won't be created.  Remove the
_hwmod suffix to conform with the rest of the OMAP SoC data.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

arch/arm/mach-omap2/timer.c pokes around inside the hwmod data
structures.  Since the hwmod data structures are about to change, this
code will break.  This patch modifies the timer code to use
recently-added hwmod functions instead.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.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: NPaul 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: NPaul 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 5365efbe
("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: NPaul 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: NPaul 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: NPaul 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: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>

Remove the pseudo-hwmods associated with hardreset lines from the
OMAP4 data file.  Future patches will convert this data to register
hwmods by interfaces, rather than registering hwmods directly.  The
pseudo-hwmods aren't associated with any interfaces, so this will
create a problem.

After this change, the hwmod code will reset processor IPs at the
hwmod level, rather than by individual hardreset lines.  So, for
example, if the IVA device driver code wishes to place one of the
sequencer cores into reset, while leaving the other active, it must do
so itself by calling the appropriate PRM functions.

This patch will cause a change in the initialization behavior of the
DSP, IVA, and IPU.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@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: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

The clocks for all DSS slave interfaces were recently changed to "dss_ick" on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and
hence the OCPIF_SWSUP_IDLE flag was needed.

Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is
now "dss_ick".  This allows the PRCM hardware to autoidle the VENC
interface clocks when they are not active, rather than relying on the
software to do it, which can keep the interface clocks active
unnecessarily.
Signed-off-by: NArchit Taneja <archit@ti.com>
[paul@pwsan.com: add a short description of the fix to the commit log]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This reverts commit f9a2f9c3.  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 2800852a ("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: NPaul 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: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NFernando 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: NPaul Walmsley <paul@pwsan.com>

I have a new optimized x86 "strncpy_from_user()" that will use these
same helper functions for all the same reasons the name lookup code uses
them.  This is preparation for that.

This moves them into an architecture-specific header file.  It's
architecture-specific for two reasons:

 - some of the functions are likely to want architecture-specific
   implementations.  Even if the current code happens to be "generic" in
   the sense that it should work on any little-endian machine, it's
   likely that the "multiply by a big constant and shift" implementation
   is less than optimal for an architecture that has a guaranteed fast
   bit count instruction, for example.

 - I expect that if architectures like sparc want to start playing
   around with this, we'll need to abstract out a few more details (in
   particular the actual unaligned accesses).  So we're likely to have
   more architecture-specific stuff if non-x86 architectures start using
   this.

   (and if it turns out that non-x86 architectures don't start using
   this, then having it in an architecture-specific header is still the
   right thing to do, of course)
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There is an extra and unnecessary call to smp_processor_id()
in cpu_bringup(). Remove it.
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The above mentioned patch checks the IOAPIC and if it contains
-1, then it unmaps said IOAPIC. But under Xen we get this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
PGD 0
Oops: 0002 [#1] SMP
CPU 0
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.2.10-3.fc16.x86_64 #1 Dell Inc. Inspiron
1525                  /0U990C
RIP: e030:[<ffffffff8134e51f>]  [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
RSP: e02b: ffff8800d42cbb70  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000ffffffef RCX: 0000000000000001
RDX: 0000000000000040 RSI: 00000000ffffffef RDI: 0000000000000001
RBP: ffff8800d42cbb80 R08: ffff8800d6400000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffef
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000010
FS:  0000000000000000(0000) GS:ffff8800df5fe000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0:000000008005003b
CR2: 0000000000000040 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff8800d42ca000, task ffff8800d42d0000)
Stack:
 00000000ffffffef 0000000000000010 ffff8800d42cbbe0 ffffffff8134f157
 ffffffff8100a9b2 ffffffff8182ffd1 00000000000000a0 00000000829e7384
 0000000000000002 0000000000000010 00000000ffffffff 0000000000000000
Call Trace:
 [<ffffffff8134f157>] xen_bind_pirq_gsi_to_irq+0x87/0x230
 [<ffffffff8100a9b2>] ? check_events+0x12+0x20
 [<ffffffff814bab42>] xen_register_pirq+0x82/0xe0
 [<ffffffff814bac1a>] xen_register_gsi.part.2+0x4a/0xd0
 [<ffffffff814bacc0>] acpi_register_gsi_xen+0x20/0x30
 [<ffffffff8103036f>] acpi_register_gsi+0xf/0x20
 [<ffffffff8131abdb>] acpi_pci_irq_enable+0x12e/0x202
 [<ffffffff814bc849>] pcibios_enable_device+0x39/0x40
 [<ffffffff812dc7ab>] do_pci_enable_device+0x4b/0x70
 [<ffffffff812dc878>] __pci_enable_device_flags+0xa8/0xf0
 [<ffffffff812dc8d3>] pci_enable_device+0x13/0x20

The reason we are dying is b/c the call acpi_get_override_irq() is used,
which returns the polarity and trigger for the IRQs. That function calls
mp_find_ioapics to get the 'struct ioapic' structure - which along with the
mp_irq[x] is used to figure out the default values and the polarity/trigger
overrides. Since the mp_find_ioapics now returns -1 [b/c the IOAPIC is filled
with 0xffffffff], the acpi_get_override_irq() stops trying to lookup in the
mp_irq[x] the proper INT_SRV_OVR and we can't install the SCI interrupt.

The proper fix for this is going in v3.5 and adds an x86_io_apic_ops
struct so that platforms can override it. But for v3.4 lets carry this
work-around. This patch does that by providing a slightly different variant
of the fake IOAPIC entries.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

To fix compile error:
drivers/usb/musb/blackfin.h:51:3: error: #error "Please use PIO mode in MUSB
driver on bf52x chip v0.0 and v0.1"
make[4]: *** [drivers/usb/musb/blackfin.o] Error 1
Signed-off-by: NBob Liu <lliubbo@gmail.com>

Add __gpio_get_value()/__gpio_set_value() to fix compile error if
CONFIG_GPIOLIB = n.
Signed-off-by: NBob Liu <lliubbo@gmail.com>

This patch fix below compile error:
"bfin-uclinux-ld: L1 data A overflow!"

It is due to the recent lib/gen_crc32table.c change:
46c5801e
crc32: bolt on crc32c

it added 8KiB more data to __cacheline_aligned which cause blackfin L1 data
cache overflow.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NBob Liu <lliubbo@gmail.com>

As described in e6fa16ab ("signal: sigprocmask() should do
retarget_shared_pending()") the modification of current->blocked is
incorrect as we need to check whether the signal we're about to block is
pending in the shared queue.

Also, use the new helper function introduced in commit 5e6292c0
("signal: add block_sigmask() for adding sigmask to current->blocked")
which centralises the code for updating current->blocked after
successfully delivering a signal and reduces the amount of duplicate
code across architectures.  In the past some architectures got this code
wrong, so using this helper function should stop that from happening
again.
Acked-by: NMark Salter <msalter@redhat.com>
Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
Acked-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As described in e6fa16ab ("signal: sigprocmask() should do
retarget_shared_pending()") the modification of current->blocked is
incorrect as we need to check for shared signals we're about to block.

Also, use the new helper function introduced in commit 5e6292c0
("signal: add block_sigmask() for adding sigmask to current->blocked")
which centralises the code for updating current->blocked after
successfully delivering a signal and reduces the amount of duplicate
code across architectures.  In the past some architectures got this code
wrong, so using this helper function should stop that from happening
again.

Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Many users of debugfs copy the implementation of default_open() when
they want to support a custom read/write function op.  This leads to a
proliferation of the default_open() implementation across the entire
tree.

Now that the common implementation has been consolidated into libfs we
can replace all the users of this function with simple_open().

This replacement was done with the following semantic patch:

<smpl>
@ open @
identifier open_f != simple_open;
identifier i, f;
@@
-int open_f(struct inode *i, struct file *f)
-{
(
-if (i->i_private)
-f->private_data = i->i_private;
|
-f->private_data = i->i_private;
)
-return 0;
-}

@ has_open depends on open @
identifier fops;
identifier open.open_f;
@@
struct file_operations fops = {
...
-.open = open_f,
+.open = simple_open,
...
};
</smpl>

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With commit c334bc15 (ARM: make mach/io.h include optional), PCMCIA was
broken. PCMCIA depends on __io() returning a valid i/o address, and most
ARM platforms require IO_SPACE_LIMIT be set to 0xffffffff for PCMCIA. This
needs a better fix with a fixed i/o address mapping, but for now we just
restore things to the previous behavior.

This fixes at91, omap1, pxa and sa11xx. pxa needs io.h if PCI is enabled,
but PCMCIA is not. sa11xx already has IO_SPACE_LIMIT set to 0xffffffff,
so it doesn't need an io.h.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Joachim Eastwood <joachim.eastwood@jotron.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Tested-by: Paul Parsons <lost.distance@yahoo.com> (pxa270)
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

"Page ready" async PF can kick vcpu out of idle state much like IRQ.
We need to tell RCU about this.
Reported-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Reviewed-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

vmx_set_cr0 is called from vcpu run context, therefore it expects
kvm->srcu to be held (for setting up the real-mode TSS).
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

Signed-off-by: NSasikantha babu <sasikanth.v19@gmail.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>