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

This board has a SSM2603 codec, so make sure we have the right resources
declared for it.
Signed-off-by: NBob Liu <lliubbo@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The RX/TX address is always the same regardless of the size of the access.
That means there is no dedicated "16bit" or "32bit" MMR.  Trying to use
these currently leads to compile errors.  So change everything to use the
right MMR define.
Signed-off-by: NBob Liu <lliubbo@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NAshish Gupta <asg@thelearninglabs.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Since these boards can boot out of NAND, make sure we give u-boot its
own partition by default to avoid clobbering it.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

If the kernel's init section is merged back into the main memory region
during boot (which it should since that is how we've laid out the kernel
linker map), we want to make sure that these aren't counted as independent
regions.  Otherwise, if a large mapping is attempted which starts in the
init region and extends into the main memory region, the access_ok func
will deny it.  This leads to weird messages during runtime like "unable
to map xxx library" from the ldso but upon running the application again,
everything works fine.

So if the address of the end of the init region is the same as the start
of the main memory region, simply enlarge the memory region to include
the init region.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Many Blackfin parts group sets of pins into a single functional unit.
This means you cannot use different pins within a group for different
peripherals.  Our resource conflict checking thus far has been limited
to individual pins, so if someone tried to grab a different pin from
the same group, it would be allowed while silently changing the other
pins in the same group.

One common example is the pin set PG12 - PG15 on BF51x parts.  They
may either be used with SPI0 (1st function), or they may be used with
PTP/PWM/AMS3 (3rd function).  Ideally, we'd like to use PG12 - PG14
for SPI0 while using PG15 with AMS3, but the hardware does not permit
this.  In the past, the software would allow the pins to be requested
this way, but ultimately things like the Blackfin SPI driver would
stop working when the hardware rerouted to a different peripheral.
Signed-off-by: Nsteven miao <realmz6@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Reported-by: ND Binderman <dcb314@hotmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Flushing caches sometimes requires anomaly workarounds which require
supervisor-only insns.  Normally we don't need to flush caches from
userspace so this isn't a problem, but when gcc generates trampolines
on the stack, we do.

So add a new syscall for gcc to use modeled after the mips version.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The BF54x processor has a ton of on-chip peripherals and in order to
support them all, the u-boot image is quite large.  So give it 512KiB
in all bootable flashes to make our lives easier.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: Nsteven miao <realmz6@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Make sure we include EMAC_SYSTAT when showing errors.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The predefined i2c address 0x2c doesn't match the configuration of the
ad5280 PINs AD0 and AD1 on the tftlcd add-on board.  Both AD0 and AD1
are of voltage 3.3V, which means the i2c address should be 0x2F.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

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

Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Nothing actually needs to use these MMRs (as direct cache manipulation
is done with the DTEST MMRs), so simply hide the read funcs behind the
anomaly define.  They're generally unusable anyways when this anomaly
is in effect.
Signed-off-by: NRobin Getz <robin.getz@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Rather than use raw numbers for the GPIO pins, use proper GPIO defines.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

When apps run with their stack in L1, some system calls might be made
where a buffer is in the stack as an argument.  So make sure the core
Blackfin access code does not reject this memory location.
Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

This board has an AD1836 codec, so make sure we have the right resources
declared for it.
Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

If an app is placing its stack in L1 scratchpad SRAM, make sure ptrace
is granted access to it so that gdb can do its thing.
Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The num_chipselect field for on-chip Blackfin SPI buses is supposed to
be 1 larger than the number of actual CSs available.  This is because
the hardware starts counting at 1 and not 0.  There is a field for "CS0",
but it is marked as "reserved" everywhere.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

We don't need our own header and structure to hook up the ad5398 part,
so drop the custom resources for it.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Rather than write our own ADP switch driver, use the existing fixed
regulator driver and rewrite the platform resources accordingly.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Some peripherals might generate an error interrupt shortly after the
data interrupt due to the fact that the peripheral isn't serviced fast
enough.  In most cases this isn't a problem and is expected behavior.
This hasn't been a problem on most parts since you simply don't request
the error interrupt (or you leave it disabled while there is an expected
state) and do the peripheral status checking in the data interrupt.

The Blackfin SIC allows people to prioritize data and error interrupts,
and the Blackfin CEC allows interrupts of equal or higher priority to
nest.  The current default settings gives error interrupts a higher
priority than data interrupts.  So if an error occurs while processing
the data interrupt, it will be serviced immediately.

However, the error interrupt on the BF537 SIC cannot be enabled on a
per-peripheral basis.  Once the error interrupt is enabled for one
peripheral, it is automatically enabled for all peripherals.

Therefore lower the default multiplexed error interrupt priority so
most people need not worry themselves with this issue.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NCliff Cai <cliff.cai@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NYi Li <yi.li@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The NAND platform driver expects the registers to have a "mem"
resource type rather than "io".
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

With the recent kernel update the isp1362-hcd driver evaluates the
IORESOURCE_IRQ resource flags and requests the irq with the given
polarity/edge settings.  However the ISP1362 config requires low
level/edge interrupts.  Most of the Blackfin boards use some random
flag or no flag at all.  Make all boards use a know good flag
IORESOURCE_IRQ_LOWEDGE.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The NAND platform driver expects the registers to have a "mem"
resource type rather than "io".
Signed-off-by: NValentin Yakovenkov <yakovenkov@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Add platform resources for the on-chip CAN peripheral so we can use it.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Make sure we use the right Kconfig names and platform strings.
Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Now that we've rewritten the GPIO CS handling in the Blackfin SPI
peripheral, we need to update the platform resources accordingly.
Signed-off-by: NBarry Song <barry.song@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Now that the common header defines everything and the SPI drivers are
using it, we can drop these duplicated global namespace polluters.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

All security modules shouldn't change sched_param parameter of
security_task_setscheduler().  This is not only meaningless, but also
make a harmful result if caller pass a static variable.

This patch remove policy and sched_param parameter from
security_task_setscheduler() becuase none of security module is
using it.

Cc: James Morris <jmorris@namei.org>
Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Set CONFIG_ARCH_DMA_ADDR_T_64BIT when we set dma_addr_t to 64 bits in
<asm/types.h>; this allows Kconfig decisions based on this property.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
LKML-Reference: <201010202255.o9KMtZXu009370@imap1.linux-foundation.org>
Acked-by: N"H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Currently flush tlb vector allocation is based on below equation:
	sender = smp_processor_id() % 8
This isn't optimal, CPUs from different node can have the same vector, this
causes a lot of lock contention. Instead, we can assign the same vectors to
CPUs from the same node, while different node has different vectors. This has
below advantages:
a. if there is lock contention, the lock contention is between CPUs from one
node. This should be much cheaper than the contention between nodes.
b. completely avoid lock contention between nodes. This especially benefits
kswapd, which is the biggest user of tlb flush, since kswapd sets its affinity
to specific node.

In my test, this could reduce > 20% CPU overhead in extreme case.The test
machine has 4 nodes and each node has 16 CPUs. I then bind each node's kswapd
to the first CPU of the node. I run a workload with 4 sequential mmap file
read thread. The files are empty sparse file. This workload will trigger a
lot of page reclaim and tlbflush. The kswapd bind is to easy trigger the
extreme tlb flush lock contention because otherwise kswapd keeps migrating
between CPUs of a node and I can't get stable result. Sure in real workload,
we can't always see so big tlb flush lock contention, but it's possible.

[ hpa: folded in fix from Eric Dumazet to use this_cpu_read() ]
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
LKML-Reference: <1287544023.4571.8.camel@sli10-conroe.sh.intel.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>