Rewrote timer_interrupt() to properly handle the "delayed!" case.

If we used floating point math to compute the number of ticks that had
elapsed since the last timer interrupt, it could take up to 12K cycles
(emperical!) to handle the interrupt. Existing code assumed it would
never take more than 8k cycles. We end up programming Interval Timer
to a value less than "current" cycle counter.  Thus have to wait until
Interval Timer "wrapped" and would then get the "delayed!" printk that
I moved below.

Since we don't really know what the upper limit is, I prefer to read
CR16 again after we've programmed it to make sure we won't have to
wait for CR16 to wrap.

Further, the printk was between reading CR16 (cycle couner) and writing CR16
(the interval timer). This would cause us to continue to set the interval
timer to a value that was "behind" the cycle counter. Rinse and repeat.
So no printk's between reading CR16 and setting next interval timer.

Tested on A500 (550 Mhz PA8600).
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Tested-by: NKyle McMartin <kyle@mcmartin.ca>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

----
Kyle, Helge, and other parisc's,
Please test on 32-bit before committing.
I think I have it right but recognize I might not.

TODO: I wanted to use "do_div()" in order to get both remainder
and value back with one division op. That should help with the
latency alot but can be applied seperately from this patch.

thanks,
grant

>>>> I think this is what was intended? Note that this patch may affect
>>>> profiling.
>>> it really should be

> >>> -    if (likely(t1 & (sizeof(unsigned int)-1)) == 0) {
> >>> +    if (likely((t1 & (sizeof(unsigned int)-1)) == 0)) {

>>> randolph
Reported-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NRandolph Chung <tausq@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

gcc 4.4 warns about:
drivers/parisc/lba_pci.c: In function 'lba_pat_resources':
drivers/parisc/lba_pci.c:1099: warning: the frame size of 8280 bytes is larger than 4096 bytes

The problem is we declare two large structures on the stack. They don't need
to be on the stack since they are only used during LBA initialization (which
is serialized). Moving to be "static".
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

This patch modifies parameter of au1x_counter1_read() from 'void' to 'struct
clocksource *cs', which fixes compile warning for incompatible parameter type.
Signed-off-by: NColy Li <coly.li@suse.de>
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Fix this build error:
arch/parisc/math-emu/decode_exc.c:351: undefined reference to `printk'
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) have
been kept around for migration reasons.  After more than two years it's
time to remove them finally.

This patch cleans up one of the remaining users.  When all such patches
hit mainline we can remove the defines and typedefs finally.

Impact: cleanup

Convert the last remaining users to struct irq_chip and remove the
define.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Fix miscompilation in arch/parisc/kernel/irq.c:
123: warning: passing arg 1 of `cpumask_setall' from incompatible pointer type
141: warning: passing arg 1 of `cpumask_copy' from incompatible pointer type
300: warning: passing arg 1 of `cpumask_copy' from incompatible pointer type
357: warning: passing arg 2 of `cpumask_copy' from incompatible pointer type
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Alex Chiang asked me why PARISC was calling pci_bus_add_devices()
and pci_bus_assign_resources() in the opposite order from everyone else.
No reason and I couldn't see any data dependency.
Patch below applies cleanly to 2.6.30-rc2.

Later, I suspected the code worked only because no drivers would be
loaded/ready until much later in the system initialization sequence.

Tested "LBA" code on J6000 (32-bit) and A500 (64-bit SMP) with 2.6.30-rc2.
Not tested with any Dino controllers.
Not tested with PCI-PCI Bridge (TBD).
Reported-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

There are two reasons to expose the memory *a in the asm:

1) To prevent the compiler from discarding a preceeding write to *a, and
2) to prevent it from caching *a in a register over the asm.

The change has had a few days testing with a SMP build of 2.6.22.19
running on a rp3440.

This patch is about the correctness of the __ldcw() macro itself.
The use of the macro should be confined to small inline functions
to try to limit the effect of clobbering memory on GCC's optimization
of loads and stores.
Signed-off-by: NDave Anglin <dave.anglin@nrc-cnrc.gc.ca>
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Doing an IPI with local interrupts off triggers a warning. We
don't need to be quite so ridiculously paranoid. Also, clean up
a bit of the code a little.
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

The atomic operations on parisc are defined as macros. The macros
includes casts which disallows the use of some syntax elements and
produces error like this:

net/phonet/pep.c: In function 'pipe_rcv_status':
net/phonet/pep.c:262: error: lvalue required as left operand of assignment

The patch removes this superfluous casts.
Signed-off-by: NBastian Blank <waldi@debian.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Acked-by: NMatthew Wilcox <willy@linux.intel.com>
Acked-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Fix this build error when CONFIG_PROC_FS is not set:
drivers/parisc/ccio-dma.c:1574: error: 'ccio_proc_info_fops' undeclared
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Fix this build error when CONFIG_STI_CONSOLE is not set
drivers/video/stifb.c:1337: undefined reference to `sti_get_rom'
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Generic compat handlers look appropriate, so use those.
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/vapier/blackfin: (27 commits)
  Blackfin: fix dma-mapping build errors
  Blackfin: hook up new perf_counter_open syscall
  Blackfin: drop BF535-specific text for exception 0x2A (unaligned instruction)
  Blackfin: fix early crash when booting on wrong cpu
  Blackfin: fix GPTMR0_CLOCKSOURCE dependency on BFIN_GPTIMERS
  Blackfin: drop unused ISP1760 port1_disable from board resources
  Blackfin: bf526-ezbrd: handle different SDRAM chips
  Blackfin: fix typo in TRAS define in mem_init.h header
  Blackfin: unify memory map headers
  Blackfin: stick the CPU name into boot image name
  Blackfin: update defconfigs
  Blackfin: decouple unrelated cache settings to get exact behavior
  Blackfin: update I-pipe patch level
  Blackfin: remove obsolete mcount support from I-pipe code
  Blackfin: allow CONFIG_TICKSOURCE_GPTMR0 with interrupt pipeline
  Blackfin: convert interrupt pipeline to irqflags
  Blackfin: allow people to select BF51x-0.1 silicon rev
  Blackfin: bf526-ezbrd: set SPI flash resources to SST device
  Blackfin: fix accidental reset in some boot modes
  Blackfin: abstract irq14 lowering in do_irq
  ...

* git://git.infradead.org/~dwmw2/iommu-2.6.31:
  intel-iommu: Fix one last ia64 build problem in Pass Through Support
  VT-d: support the device IOTLB
  VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
  VT-d: add device IOTLB invalidation support
  VT-d: parse ATSR in DMA Remapping Reporting Structure
  PCI: handle Virtual Function ATS enabling
  PCI: support the ATS capability
  intel-iommu: dmar_set_interrupt return error value
  intel-iommu: Tidy up iommu->gcmd handling
  intel-iommu: Fix tiny theoretical race in write-buffer flush.
  intel-iommu: Clean up handling of "caching mode" vs. IOTLB flushing.
  intel-iommu: Clean up handling of "caching mode" vs. context flushing.
  VT-d: fix invalid domain id for KVM context flush
  Fix !CONFIG_DMAR build failure introduced by Intel IOMMU Pass Through Support
  Intel IOMMU Pass Through Support

Fix up trivial conflicts in drivers/pci/{intel-iommu.c,intr_remapping.c}

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: new stack is no longer experimental
  firewire: net: better FIFO address range check and rcodes
  firewire: net: fix card driver reloading
  firewire: core: fix iso context shutdown on card removal
  firewire: core: fix DMA unmapping in iso buffer removal
  firewire: net: adjust net_device ops
  firewire: net: remove unused code
  firewire: net: allow for unordered unit discovery
  firewire: net: style changes
  firewire: net: add Kconfig item, rename driver
  firewire: add IPv4 support

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As noted in the previous patch, the NFSv4 client mount code currently
has several limitations. If the mount path contains symlinks, or
referrals, or even if it just contains a '..', then the client code in
nfs4_path_walk() will fail with an error.

This patch replaces the nfs4_path_walk()-based lookup with a helper
function that sets up a private namespace to represent the namespace on the
server, then uses the ordinary VFS and NFS path lookup code to walk down the
mount path in that namespace.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The purpose of this patch is to improve the remote mount path lookup
support for distributed filesystems such as the NFSv4 client.

When given a mount command of the form "mount server:/foo/bar /mnt", the
NFSv4 client is required to look up the filehandle for "server:/", and
then look up each component of the remote mount path "foo/bar" in order
to find the directory that is actually going to be mounted on /mnt.
Following that remote mount path may involve following symlinks,
crossing server-side mount points and even following referrals to
filesystem volumes on other servers.

Since the standard VFS path lookup code already supports walking paths
that contain all these features (using in-kernel automounts for
following referrals) we would like to be able to reuse that rather than
duplicate the full path traversal functionality in the NFSv4 client code.

This patch therefore defines a VFS helper function create_mnt_ns(), that
sets up a temporary filesystem namespace and attaches a root filesystem to
it. It exports the create_mnt_ns() and put_mnt_ns() function for use by
filesystem modules.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In order to allow modules to use it without having to export vfsmount_lock.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

SLAB uses get/put_online_cpus() which use a mutex which is itself only
initialized when cpu_hotplug_init() is called.  Currently we hang suring
boot in SLAB due to doing that too late.

Reported by James Bottomley and Sachin Sant (and possibly others).
Debugged by Benjamin Herrenschmidt.

This just removes the dynamic initialization of the data structures, and
replaces it with a static one, avoiding this dependency entirely, and
removing one unnecessary special initcall.
Tested-by: NSachin Sant <sachinp@in.ibm.com>
Tested-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Tested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The recent deprecation of dma_sync_{sg,single} ironically broke Blackfin
systems.  This is because we don't define dma_sync_sg_for_cpu at all, so
until the DMA asm-generic conversion/cleanup is done after the next
release, simply stub out the dma_sync_sg_for_{cpu,device} functions.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NMike Frysinger <vapier@gentoo.org>

We don't support the BF535 at all, and the exception 0x2A text specific to
it is pretty verbose and confusing (since the behavior is simply odd), so
punt it to keep the noise down.
Signed-off-by: NYi Li <yi.li@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Make sure we process the kernel command line before poking the hardware,
so that we can process early printk.  This helps ensure that if you boot
a kernel configured for a different processor, something will be left in
the log buffer.
Signed-off-by: NRobin Getz <robin.getz@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The GPTMR0_CLOCKSOURCE Kconfig option requires the gptimers framework, so
make sure it is selected when this option is enabled.
Reported-by: NPeter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The port1 disable stuff was dropped from the USB ISP1760, so update the
Blackfin boards accordingly.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The BF526-EZBRD changed SDRAM chips between board revisions, so create a
timing table that can accommodate both.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

We defined SDRAM_tRAS to TRAS_4, but then wrongly defined SDRAM_tRAS_num
to 3.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Many aspects of the Blackfin memory map is exactly the same across all
variants.  Rather than copy and paste all of these duplicated values in
each header, unify all of these into the common Blackfin memory map header
file.  In the process, push down BF561 SMP specific stuff to the BF561
specific header to keep the noise down.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Rather than use "Linux" in the boot image name (as this is redundant --
the image type is already set to "linux"), use the CPU name.  This makes
it fairly obvious when a wrong image is accidentally booted.  Otherwise
there is no kernel output and you waste time scratching your head
wondering wtf just happened.
Signed-off-by: NRobin Getz <rgetz@blackfin.uclinux.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The current cache options don't really represent the hardware features.
They end up setting different aspects of the hardware so that the end
result is to turn on/off the cache.  Unfortunately, when we hit cache
problems with the hardware, it's difficult to test different settings to
root cause the problem.  The current settings also don't cleanly allow for
different caching behaviors with different regions of memory.

So split the configure options such that they properly reflect the settings
that are applied to the hardware.
Signed-off-by: NJie Zhang <jie.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NPhilippe Gerum <rpm@xenomai.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NPhilippe Gerum <rpm@xenomai.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NPhilippe Gerum <rpm@xenomai.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NPhilippe Gerum <rpm@xenomai.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>