vm: add vm_iomap_memory() helper function

commit b4cbb197c7e7a68dbad0d491242e3ca67420c13e upstream.

Various drivers end up replicating the code to mmap() their memory
buffers into user space, and our core memory remapping function may be
very flexible but it is unnecessarily complicated for the common cases
to use.

Our internal VM uses pfn's ("page frame numbers") which simplifies
things for the VM, and allows us to pass physical addresses around in a
denser and more efficient format than passing a "phys_addr_t" around,
and having to shift it up and down by the page size.  But it just means
that drivers end up doing that shifting instead at the interface level.

It also means that drivers end up mucking around with internal VM things
like the vma details (vm_pgoff, vm_start/end) way more than they really
need to.

So this just exports a function to map a certain physical memory range
into user space (using a phys_addr_t based interface that is much more
natural for a driver) and hides all the complexity from the driver.
Some drivers will still end up tweaking the vm_page_prot details for
things like prefetching or cacheability etc, but that's actually
relevant to the driver, rather than caring about what the page offset of
the mapping is into the particular IO memory region.

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Staging: TIDSPBRIDGE: Use vm_iomap_memory for mmap-ing instead of remap_pfn_range

This fixes the following bug:

----  Bug Report ----

source file: drivers/staging/tidspbridge/rmgr/drv_interface.c
issue      : mapping of physical memory without address range checks

259 static int bridge_mmap(struct file *filp, struct vm_area_struct *vma)
260 {
261         u32 status;
262
263         /* VM_IO | VM_DONTEXPAND | VM_DONTDUMP are set by remap_pfn_range() */
264         vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
265
266         dev_dbg(bridge, "%s: vm filp %p start %lx end %lx page_prot %ulx "
267                 "flags %lx\n", __func__, filp,
268                 vma->vm_start, vma->vm_end, vma->vm_page_prot,
269                 vma->vm_flags);
270
271         status = remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
272                                  vma->vm_end - vma->vm_start,
273                                  vma->vm_page_prot);
274         if (status != 0)
275                 status = -EAGAIN;
276
277         return status;
278 }

The function provides an interface to remap physical memory to user space, but
does not provide any checks to ensure that the memory is within the region that
should be accessible.

Reported-by: Nico Golde <nico@ngolde.de>
Reported-by: Fabian Yamaguchi <fabs@goesec.de>

Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
[steven@steven676.net: make apply to omapzoom p-android-omap3-3.0 branch]

Change-Id: Ie8bb7d62efc5fd5b8f314c229df55c633550dec0
tidspbridge: fix last patch to map same region of physical memory as before

Commit 559c71fe5dc3 ("Staging: TIDSPBRIDGE: Use vm_iomap_memory for
mmap-ing instead of remap_pfn_range") had the effect of inadvertently
shifting the start of the physical memory area mapped by
pdata->phys_mempool_base.  Correct this by subtracting that shift before
calling vm_iomap_memory() and adding it back afterwards.

Reported-by: Dheeraj CVR <cvr.dheeraj@gmail.com>
Signed-off-by: Steven Luo <steven@steven676.net>
tidspbridge: fix last patch to map same region of physical memory as before

Commit 559c71fe5dc3 ("Staging: TIDSPBRIDGE: Use vm_iomap_memory for
mmap-ing instead of remap_pfn_range") had the effect of inadvertently
shifting the start of the physical memory area mapped by
pdata->phys_mempool_base.  Correct this by subtracting that shift before
calling vm_iomap_memory() and adding it back afterwards.

Reported-by: Dheeraj CVR <cvr.dheeraj@gmail.com>
Signed-off-by: Steven Luo <steven@steven676.net>
Revert "mach: latona: use dpll3_m2_ck to increase L3 clocks"

L3 overclocking has issues on latona. There are reported stability
issues and few devices refuse to boot. Revert the voltage and clocks
to the default

This reverts commit b9c8f6875fe97b7690ec217d05f8bf38a4b630d1.
Merge branch 'latona-3.0' of git://github.com/sconosciuto/android_kernel_samsung_latona into cm-11.0
Merge branch 'cm-11.0' of git://github.com/dhiru1602/android_kernel_samsung_latona into cm-11.0