The initialisation process differs for CONFIG_PMB and for
CONFIG_PMB_FIXED. For CONFIG_PMB_FIXED we need to register the PMB
entries that were allocated by the bootloader.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

We need to map the gap between 0x00000000 and __MEMORY_START in the PMB,
as well as RAM.

With this change my 7785LCR board can switch to 32bit MMU mode at
runtime.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Eventually we'll have complete control over what physical memory gets
mapped where and we can probably do other interesting things. For now
though, when the MMU is in 32-bit mode, we map physical memory into the
P1 and P2 virtual address ranges with the same semantics as they have in
29-bit mode.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Unfortunately, at the time during in boot when we want to be setting up
the PMB entries, the kmem subsystem hasn't been initialised.

We now match pmb_map slots with pmb_entry_list slots. When we find an
empty slot in pmb_map, we set the bit, thereby acquiring the
corresponding pmb_entry_list entry. There is a benefit in using this
static array of struct pmb_entry's; we don't need to acquire any locks
in order to traverse the list of struct pmb_entry's.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

There's no need to export the internal PMB functions for allocating,
freeing and modifying PMB entries, etc. This way we can restrict the
interface for PMB.

Also remove the static from pmb_init() so that we have more freedom in
setting up the initial PMB entries and turning on MMU 32bit mode.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

CONFIG_PMB will eventually allow the MMU to be switched between 29-bit
and 32-bit mode dynamically at runtime.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

To allow the MMU to be switched between 29bit and 32bit mode at runtime
some constants need to swapped for functions that return a runtime
value.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Replace the use of PHYSADDR() with __pa(). PHYSADDR() is based on the
idea that all addresses in P1SEG are untranslated, so we can access an
address's physical page as an offset from P1SEG. This doesn't work for
CONFIG_PMB/CONFIG_PMB_FIXED because pages in P1SEG and P2SEG are used
for PMB mappings and so can be translated to any physical address.

Likewise, replace a P1SEGADDR() use with virt_to_phys().
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Simplify set_pmb_entry() by removing the possibility of not finding a
free slot in the PMB. Instead we now allocate a slot in pmb_alloc() so
that if there are no free slots we fail at allocation time, rather than
in set_pmb_entry().
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Currently, we've got the less than ideal situation where if we need to
allocate a 256MB mapping we'll allocate four entries like so,

	 entry 1: 128MB
	 entry 2:  64MB
	 entry 3:  16MB
	 entry 4:  16MB

This is because as we execute the loop in pmb_remap() we will
progressively try mapping the remaining address space with smaller and
smaller sizes. This isn't good because the size we use on one iteration
may be the perfect size to use on the next iteration, for instance when
the initial size is divisible by one of the PMB mapping sizes.

With this patch, we now only need two entries in the PMB to map 256MB of
address space,

	  entry 1: 128MB
	  entry 2: 128MB
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

We should favour PMB mappings when the physical address cannot be
reached with 29-bits.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

If we fail to allocate a PMB entry in pmb_remap() we must remember to
clear and free any PMB entries that we may have previously allocated,
e.g. if we were allocating a multiple entry mapping.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Fix some callers of jump_to_uncached() and back_to_cached() that were
not annotated with __uses_jump_to_uncached.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Extend the ecovec24 board code to enable Power
Management LEDs showing the current sh7724 sleep state.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Now that range timers and deferred timers are common, I found a
problem with these using the "perf timechart" tool. Frans Pop also
reported high scheduler latencies via LatencyTop, when using
iwlagn.

It turns out that on x86, these two 'opportunistic' timers only get
checked when another "real" timer happens. These opportunistic
timers have the objective to save power by hitchhiking on other
wakeups, as to avoid CPU wakeups by themselves as much as possible.

The change in this patch runs this check not only at timer
interrupts, but at all (device) interrupts. The effect is that:

 1) the deferred timers/range timers get delayed less

 2) the range timers cause less wakeups by themselves because
    the percentage of hitchhiking on existing wakeup events goes up.

I've verified the working of the patch using "perf timechart", the
original exposed bug is gone with this patch. Frans also reported
success - the latencies are now down in the expected ~10 msec
range.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Tested-by: NFrans Pop <elendil@planet.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091008064041.67219b13@infradead.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Blackfin already sets proper flow handlers on all IRQs, and we don't rely
on __do_IRQ, therefore we can simply select GENERIC_HARDIRQS_NO__DO_IRQ.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The simple-gpio has been replaced by the gpio sysfs interface, so drop the
unused simple-gpio resources from all Blackfin boards.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The patch added a special get_unmapped_area for framebuffer which
was hooked to the file ops in drivers/video/fbmem.c.

This is needed since v2.6.29-rc1 where nommu vma management was
updated, and mmap of framebuffer caused kernel BUG panic. You may turn
on "Debug the global anon/private NOMMU mapping region tree" config to
such message.

As Documentation/nommu-mmap.txt said,
"To provide shareable character device support, a driver must provide
a file->f_op->get_unmapped_area() operation. The mmap() routines will
call this to get a proposed address for the mapping."

With this change, user space should call mmap for framebuffer using
shared map. Or it can try shared map first, then private map if
failed. This shared map usage is now consistent between mmu and nommu.

The sys_ file may not be a good place for this patch. But there is a
similar one for sparc. I tested a similar patch on nios2nommu, though
I don't have a blackfin board to test.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Fix the following 'make includecheck' warning:

  arch/blackfin/mach-bf548/boards/ezkit.c: linux/input.h is included more than once.
Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Structs get initialized to 0 already, and we want to punt this field, so
scrub it from all of our boards.
Reported-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Now that the common jedec_probe supports the ST PSD4256G6V, no need to
use the custom stm_flash driver.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Now that the driver has been updated, convert the board resources to the
new i2c framework for managing slaves.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Looks like the big Kconfig cache split/rename missed one spot in the SMP
cache lock headers.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The cplbinfo was using d_path() to figure out which cpu/cplb was being
parsed.  As Al pointed out, this isn't exactly reliable as it assumes the
static VFS path to be unchanged, and it's just poor form.  So use the
proc_create_data() to properly (and internally) pass the exact cpu/cplb
requested to the parser function.
Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

The asm/irq.h header uses anomaly defines, but doesn't make sure to
explicitly include the anomaly header for them.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Bill Gatliff & David Brownell pointed out we were missing some
copyrights, and licensing terms in some of the files in
./arch/blackfin, so this fixes things, and cleans them up.

It also removes:
 - verbose GPL text(refer to the top level ./COPYING file)
 - file names (you are looking at the file)
 - bug url (it's in the ./MAINTAINERS file)
 - "or later" on GPL-2, when we did not have that right

It also allows some Blackfin-specific assembly files to be under a BSD
like license (for people to use them outside of Linux).
Signed-off-by: NRobin Getz <robin.getz@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

Convert Blackfin to use GENERIC_TIME via the arch_getoffset()
infrastructure, reducing the amount of arch specific code we need to
maintain.

I've taken my best swing at converting this, but I'm not 100% confident
I got it right.  My cross-compiler is now out of date (gcc4.2) so I
wasn't able to check if it compiled. Any assistance from arch
maintainers or testers to get this merged would be great.
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>

I was using Coccinelle with the mutex_unlock semantic patch, and it
unconvered this problem. It appears to be a valid missing unlock issue.
This change should correct it by moving the unlock below the label.

This patch is against the mainline kernel.

Cc: Julia Lawall <julia@diku.dk>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NDaniel Walker <dwalker@fifo99.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix incorrect spelling
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

the original flush operation is to flush the function address which is
copied from.
But we do not change the function code and it is not necessary to flush it.
Signed-off-by: Njanboe <janboe.ye@gmail.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Some architectures such as Sparc, ARM and MIPS (basically
everything with flush_dcache_page()) need to deal with dcache
aliases by carefully placing pages in both kernel and user maps.

These architectures typically have to use vmalloc_user() for this.

However, on other architectures, vmalloc() is not needed and has
the downsides of being more restricted and slower than regular
allocations.
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NDavid Miller <davem@davemloft.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1254830228.21044.272.camel@laptop>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

The original driver was written with the KEY() macro defined as (col,
row) instead of (row, col) as defined by the matrix keypad
infrastructure. So the keymap was defined accordingly. Since the
driver that was merged upstream uses the matrix keypad infrastructure,
modify the keymap accordingly.

While we are at it, fix the comments in twl4030.h and define
PERSISTENT_KEY as (r,c) instead of (c, r)

Tested on a RX51 (N900) device.
Signed-off-by: NAmit Kucheria <amit.kucheria@verdurent.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Lock DPLL5 at 120MHz at boot. The USBHOST 120MHz f-clock and
USBTLL f-clock are the only users of this DPLL, and 120MHz is
is the only recommended rate for these clocks.

With this patch, the 60 MHz ULPI clock is generated correctly.

Tested on an OMAP3430 SDP.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit cd922049 added
support for omap850. However, the patch accidentally
removed the wrong ifdef:

 #  define cpu_is_omap730()		1
 # endif
 #endif
+#else
+# if defined(CONFIG_ARCH_OMAP850)
+#  undef  cpu_is_omap850
+#  define cpu_is_omap850()		1
+# endif
+#endif

...

 void omap2_check_revision(void);

 #endif    /* defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) */
-
-#endif

Instead of removing removing the #endif at the end of the file,
the #endif before #else should have been removed.

But we cannot have multiple #else statements as pointed out by
Alistair Buxton <a.j.buxton@gmail.com>. So the fix is to:

- remove the non-multi-omap special handling, as we need to
  detect between omap730 and omap850 anyways.

- add the missing #endif back to the end of the file
Reported-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The 'pwrdm_for_each()' function walks powerdomains with a spinlock
locked, so the the callbacks cannot do anything which may sleep.
This patch introduces a 'pwrdm_for_each_nolock()' helper which does
the same, but without the spinlock locked. This fixes the following
lockdep warning:

[    0.000000] WARNING: at kernel/lockdep.c:2460 lockdep_trace_alloc+0xac/0xec()
[    0.000000] Modules linked in:
(unwind_backtrace+0x0/0xdc) from [<c0045464>] (warn_slowpath_common+0x48/0x60)
(warn_slowpath_common+0x48/0x60) from [<c0067dd4>] (lockdep_trace_alloc+0xac/0xec)
(lockdep_trace_alloc+0xac/0xec) from [<c009da14>] (kmem_cache_alloc+0x1c/0xd0)
(kmem_cache_alloc+0x1c/0xd0) from [<c00b21d8>] (d_alloc+0x1c/0x1a4)
(d_alloc+0x1c/0x1a4) from [<c00a887c>] (__lookup_hash+0xd8/0x118)
(__lookup_hash+0xd8/0x118) from [<c00a9f20>] (lookup_one_len+0x84/0x94)
(lookup_one_len+0x84/0x94) from [<c010d12c>] (debugfs_create_file+0x8c/0x20c)
(debugfs_create_file+0x8c/0x20c) from [<c010d320>] (debugfs_create_dir+0x1c/0x20)
(debugfs_create_dir+0x1c/0x20) from [<c000e8cc>] (pwrdms_setup+0x60/0x90)
(pwrdms_setup+0x60/0x90) from [<c002e010>] (pwrdm_for_each+0x30/0x80)
(pwrdm_for_each+0x30/0x80) from [<c000e79c>] (pm_dbg_init+0x7c/0x14c)
(pm_dbg_init+0x7c/0x14c) from [<c00232b4>] (do_one_initcall+0x5c/0x1b8)
(do_one_initcall+0x5c/0x1b8) from [<c00083f8>] (kernel_init+0x90/0x10c)
(kernel_init+0x90/0x10c) from [<c00242c4>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Currently, only GPIOs in the wakeup domain (GPIOs in bank 0) are
enabled as wakups.  This patch also enables GPIOs in the PER
powerdomain (banks 2-6) to be used as possible wakeup sources.

In addition, this patch ensures that all GPIO wakeups can wakeup
the MPU using the PM_MPUGRPSEL_<pwrdm> registers.

NOTE: this doesn't enable the individual GPIOs as wakeups, this simply
enables the per-bank wakeups at the powerdomain level.

This problem was discovered by Mike Chan when preventing the CORE
powerdomain from going into retention/off.  When CORE was allowed to
hit retention, GPIO wakeups via IO pad were working fine, but when
CORE remained on, GPIO module-level wakeups were not working properly.

To test, prevent CORE from going inactive/retention/off, thus
preventing the IO chain from being armed:

  # echo 3 > /debug/pm_debug/core_pwrdm/suspend

This ensures that GPIO wakeups happen via module-level wakeups and
not via IO pad.

Tested on 3430SDP using the touchscreen GPIO (gpio 2, in WKUP)
Tested on Zoom2 using the QUART interrup GPIO  (gpio 102, in PER)

Also, c.f. OMAP PM wiki for troubleshooting GPIO wakeup issues:
http://elinux.org/OMAP_Power_ManagementReported-by: NMike Chan <mikechan@google.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

USBHOST module has 2 fclocks (for HOST1 and HOST2), only one iclock
and only a single bit in the WKST register to indicate a wakeup event.

Because of the single WKST bit, we cannot know whether a wakeup event
was on HOST1 or HOST2, so enable both fclocks before clearing the
wakeup event to ensure both hosts can properly clear the event.
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>

Clearing wakeup sources is now only done when the PRM indicates a
wakeup source interrupt.  Since we don't handle any other types of
PRCM interrupts right now, warn if we get any other type of PRCM
interrupt.  Either code needs to be added to the PRCM interrupt
handler to react to these, or these other interrupts should be masked
off at init.

Updated after Jon Hunter's PRCM IRQ rework by Kevin Hilman.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>