Fix unused code warning in arch/arm/plat-s3c24xx/dma.c if there
is no PM support enabled. The function to_dma_chan() should
be marked inline so that the compiler will eliminate it without
warning if it isn't used.

arch/arm/plat-s3c24xx/dma.c:1239: warning: 'to_dma_chan' defined but not used
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

As per Russell King's last review comment, find and remove
all unnecessary includes of <linux/delay.h> in the files
that do not need them.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

When ISA_DMA_API is unset, we're not implementing the ISA DMA API,
so there's no point in publishing the prototypes via asm/dma.h, nor
including the machine dependent parts of that API.

This allows us to remove a lot of mach/dma.h files which don't contain
any useful code.  Unfortunately though, some platforms put their own
private non-ISA definitions into mach/dma.h, so we leave these behind
and fix the appropriate #include statments.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Continue moving the include files into arch/arm
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove includes of asm/hardware.h in addition to asm/arch/hardware.h.
Then, since asm/hardware.h only exists to include asm/arch/hardware.h,
update everything to directly include asm/arch/hardware.h and remove
asm/hardware.h.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Kmem cache passed to constructor is only needed for constructors that are
themselves multiplexeres.  Nobody uses this "feature", nor does anybody uses
passed kmem cache in non-trivial way, so pass only pointer to object.

Non-trivial places are:
	arch/powerpc/mm/init_64.c
	arch/powerpc/mm/hugetlbpage.c

This is flag day, yes.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
Acked-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Jon Tollefson <kniht@linux.vnet.ibm.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Matt Mackall <mpm@selenic.com>
[akpm@linux-foundation.org: fix arch/powerpc/mm/hugetlbpage.c]
[akpm@linux-foundation.org: fix mm/slab.c]
[akpm@linux-foundation.org: fix ubifs]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix the channel parameter to s3c2410_dma_ctrl() in s3c2410_dma_enqueue()
if the S3C2410_DMAF_AUTOSTART is set on the channel.

Spotted by Steven Ryu at Samsung.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The s3c2410_dma_request() function should return the channel allocated
instead of zero for success.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If an DMA channel was active at suspend, then ensure that
it is correctly reconfigured when the system resumes.

Note, the previous policy was for each driver to handle their
own reconfiguration on resume. The policy has been changed to
make the individual driver's job easier.
Signed-off-by: NBen Dooks <ben-linux@flfuf.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The current S3C24XX DMA code does not allow for an peripheral
that has one channel for RX and another for TX.

This patch adds a per-cpu dma operation to select the transmit
or receive channel, and adds support to the S3C2412 for the
seperate DMA channels for TX and RX.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

All kobjects require a dynamically allocated name now. We no longer
need to keep track if the name is statically assigned, we can just
unconditionally free() all kobject names on cleanup.
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Slab constructors currently have a flags parameter that is never used.  And
the order of the arguments is opposite to other slab functions.  The object
pointer is placed before the kmem_cache pointer.

Convert

        ctor(void *object, struct kmem_cache *s, unsigned long flags)

to

        ctor(struct kmem_cache *s, void *object)

throughout the kernel

[akpm@linux-foundation.org: coupla fixes]
Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch removes section mismatches related to DMA functions.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Acked-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Slab destructors were no longer supported after Christoph's
c59def9f change. They've been
BUGs for both slab and slub, and slob never supported them
either.

This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Spelling fixes in arch/arm/.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix the following sparse errors in arch/arm/plat-s3c24xx/dma.c:

dma.c:47:30: warning: symbol 'dma_sel' was not declared. Should it be static?
dma.c:883:6: warning: symbol 's3c2410_dma_waitforstop' was not declared. Should it be static?
dma.c:961:1: warning: symbol 's3c2410_dma_started' was not declared. Should it be static?
dma.c:1283:12: warning: symbol 's3c24xx_dma_sysclass_init' was not declared. Should it be static?
dma.c:1295:12: warning: symbol 's3c24xx_dma_sysdev_register' was not declared. Should it be static?
dma.c:1399:25: warning: symbol 's3c2410_dma_map_channel' was not declared. Should it be static?

The patch makes all the relevant functions static.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch gets the DMA system for the S3C24XX
ready for the S3C2443, which requires 6 dma channels
at a different stride, and different base IRQ.

The DMA system is now initialised from the same
drivers which apply the DMA mappings, as well
as removing the DMA sysdev intialisation out of
the main init code (which is now being called
from a sysdev probe, so cannot add a new sysdev)
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the DMA code's channel printing at startup
as this is firstly a waste of console output on
initialsaion, and secondly is going to be obsolete
once the S3C2443 DMA code has been merged
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Allow the CPU code, and any board specific initialisation
code to change the allocation order of the DMA channels,
or stop a peripheral allocating any DMA at-all.

This is due to the scarce mapping of DMA channels on
some earlier S3C24XX cpus, where the selection changes
depending on the channel in use.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The following patch and script moves the arch/arm/mach-s3c2410
directory into arch/arm/plat-s3c24xx for the generic core code
and inti arch/arm/mach-s3c{cpu} for the cpu/machine support files

Include directory include/asm-arm/plat-s3c24xx is added for the
core include files.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The commit 505788cc in linus kernel tree
introduced some printks (for debugging ?) which are flooding the logs on
my h1940. This patch replace them with pr_debug calls.
Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix the copyright messages in arch/arm/mach-s3c2410
to actually have `Copyright` in the line.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Replace all uses of kmem_cache_t with struct kmem_cache.

The patch was generated using the following script:

	#!/bin/sh
	#
	# Replace one string by another in all the kernel sources.
	#

	set -e

	for file in `find * -name "*.c" -o -name "*.h"|xargs grep -l $1`; do
		quilt add $file
		sed -e "1,\$s/$1/$2/g" $file >/tmp/$$
		mv /tmp/$$ $file
		quilt refresh
	done

The script was run like this

	sh replace kmem_cache_t "struct kmem_cache"
Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Untested, but this should fix up the bulk of the totally mechanical
issues, and should make the actual detail fixing easier.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Allow each CPU type in the S3C24XX range to
select the DMA channel mapping it supports.

We change the DMA registration to use an
virtual channel number that the DMA system
will allocate to a hardware channel at
request time.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

The type naming in the s3c24xx dma code is riddled with
typedefs creating _t types, from the code import from 2.4
which is contrary to the current Kernel coding style.

This patch cleans this up, removing the typedefs and
and fixing up the resultant code changes.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

A number of small issues with the S3C24XX DMA have
cropped up, which this patch fixes. These are:

  - check wether we can load another buff in start
  - update state handling in s3c2410_dma_lastxfer
  - only reload in irq if channel is not idle
  - more informative timeout errors (add source)
  - do not call request_irq() with irqs locked
  - added waitforstop function

The patch also adds a S3C2410_DMAOP_STARTED for
the occasions when the driver wants to ensure that
the DMA system load state is resynced after loading.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The irgflags consolidation did conflict with the ARM to generic IRQ
conversion and was not applied for ARM. Fix it up.

Use the new IRQF_ constants and remove the SA_INTERRUPT define
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Patch from Lucas Correia Villa Real

This patch defines S3C2400 memory map and adds a S3C24XX macro for
common resources between S3C2400, S3C2410 and S3C2440 cpus.
Signed-off-by: NLucas Correia Villa Real <lucasvr@gobolinux.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Lucas Correia Villa Real

This patch replaces the sizeof()'s %d specifier by %ld on a S3C2410 DMA
printk.
Signed-off-by: NLucas Correia Villa Real <lucasvr@gobolinux.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Albrecht Dre

Problem:
When a module requests a DMA channel via the function s3c2410_dma_request(), this function requests the appropriate irq under the name of the client module. When the client module is unloaded, it calls s3c2410_dma_free() which does not free the irq. Consequently, when e.g. running "cat /proc/interrupts", the irq owner points to freed memory, leading to a kernel oops.
File:
linux/arch/arm/mach-s3c2410/dma.c
Fix:
trivial, below

Signed-off-by: Albrecht Dre
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!