The multimedia firmware on 8960 will always be
loaded into a fixed address, and all callers into
this firmware must be no more than 256M above the
start of this firmware.
This implies that the the mm ION heap and its associated heaps
(mm_fw and mfc) must also be created in a fixed place.
This version of the patch keeps the mm fw heap size
to 2M for compatibility with the current tip. This
will eventually be reduced to 1M.
Change-Id: I35f89b8c60165fb0adbb9d04412e0e200117beb9
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop memory.c changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Due to limitations in the multimedia architecure
clients might not know when a buffer can be unmapped
from the IOMMU. In addition, the multimedia architecture
causes unnecessary mappings/unmappings for the same buffers
which reduces framerates.
Add logic to delay unmapping from the IOMMU
until buffer memory is freed and unmap any outstanding
mappings to avoid virtual memory address space leak.
Change-Id: Idaeae269d9ba623e25a0cb087a89b4cbb63915af
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Clients need to be able to do cache operations
on ION buffers in the kernel. Add API to
flush, invalidate, or invalidate and flush the
cache of an ION buffer.
Change-Id: I2b676dbe32372b3c17e4aaf39f51878b105a699c
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
There exists one definition for ion_map_iommu
function when ION is enabled and one definition when
ION is disabled. The argument list for the definition used
when ION is disabled is missing the buffer_size argument causing
compilation error for targets that call this function without
ION enabled.
Add buffer_size argument to ion_map_iommu function
for targets that does not have ION enabled.
Change-Id: Ie184e4a6dbec2bc3dff75ab3b25985fd64e2baac
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Video hardware has the following requirements for
ION heaps:
1. MM heap must be at a higher address than FW heap.
2. MFC heap must at a higher address than FW
3. MM heap must be adjacent to FW heap.
(There cannot be another heap between FW and MM heap)
4. MM and MFC heap cannot be more than 256MB away
from the base address of the FW heap.
MM heap is configured as a reusable heap (FMEM heap) and FMEM
is carved out at a much higher address than the other heaps breaking
the above requirements. To support the above requirements the
MFC heap together with the FW heap must be carved out at the same
location as MM heap.
Change-Id: Ie0acb4b267d4307190ea3cd9ff23c710ffa1a538
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop fmem changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Video requires the IOMMU heap to be at a lower
priority so that video can try to allocate from
its MM carveout heap first and then if video needs
more memory and the MM heap is exhausted it will
automatically fall back on IOMMU heap.
Change the priority of the IOMMU heap so video
can fall back on IOMMU heap.
Change-Id: Id1fc19e2c3af18ced028132d1a1bdb6a3935380f
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
FMEM allows ION to release memory for other
purposes when ION clients are not using the
memory.
Add new heap type for fmem that make calls
into fmem API to transition memory from T to
C state and vice versa. Add support for
fmem to content protection heap.
Change-Id: I95f949b57c99949e6eafe6a6f5fd147bdaa264f6
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ION has to guarantee that two of the heaps are
adjacent to each other. This is due to a limitation
in the hardware. Add code to ensure these heaps
are adjacent.
Change-Id: Icc18437a50e1d872112468d02b61ab47fd70acc9
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop board file changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Refactor platform data to allow for better
expansion in the future. Add void * for
elements unique to each heap type.
Change-Id: I435679819c67ce917b5798009eff7e71047fd2ea
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop board file changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Secure buffers provides a way to allow premium encrypted
multimedia content to be decrypted in a secured
memory area that does not allow for interception of the
decrypted content.
Add support for heap type that allow heap to be
used for content protection. Introduce new content
protection heap type and id's.
Change-Id: Idd56aa8805b5b74d1b9ab3fe8964aacc218668c1
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop board file and scm.h changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add heap ids for ion heaps. Remove unused
system contiguous heap. Fix vmalloc heap name.
Change-Id: I3c3a653a53c8db8b66a7bba2abac0dfe560c407c
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop board file changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Callbacks to request_region, release_region,
setup_region is missing from ION platform data for
SMI heap.
Change-Id: Ida603d4ac7c3246c0deedb9b80dc0c1ea64638eb
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[sboyd: drop board file changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add infrastructure to support mapping allocations
into iommus.
Change-Id: Ia5eafebee408e297013bf55284abf67d9eb8d78b
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
[sboyd: drop board file changes]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This change is part of the move from PMEM to ION. ION needs an SMI
voting interface smiliar to PMEM's.
Change-Id: I18888f46198848694fb7e1e0d2671074bf51d7c9
Signed-off-by: Alex Bird <alexbird@codeaurora.org>
Userspace clients pass fds around, not handles. Support flushing
via fd.
Change-Id: Ic22d9327e9fa72cb604c3010a2a6f798be8dfdb1
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
As part of the transition from PMEM to ION, the interface for accessing
SMI memory needs to be accessible from ION as it was from PMEM.
Change-Id: Ia6f9475dc030bbb0dafdcc1b6dbe93c7cdeca268
Signed-off-by: Alex Bird <alexbird@codeaurora.org>
Add support for Ion
Change-Id: I1c04b8a6df005c6ced8681f419f4445592b4832d
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
[sboyd: only ion header]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add err.h for the declaration of ERR_PTR which
is used with the stubbed out ion headers.
Change-Id: Ic5e5aea556723ea6b9c8953ef54ad5a82d3761ec
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add adsp heaps for ion. This corresponds directly
to what pmem currently does. This also includes disabling
the adsp and pmem heaps for pmem.
Change-Id: I4354c713413ebbe949579741efdd75e9c444c8e7
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
[sboyd: only ion header]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add inline stubs for in-kernel Ion functions to use when
Ion is not enabled in the kernel config.
Change-Id: Ic0dedbadbe4d7bab8f24763e67dd775c769b06df
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Clients may want to know what the existing flags are on a
handle for mapping, cache flushing or other purposes. Add
an API to get those flags.
Change-Id: I2d8c93194d1fc940042529b8851ebecf35d6e3de
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Make sure the header file for Ion gets exported to userspace.
Also make sure userspace can actually use the header.
Change-Id: I44f436005a6a503811c85d4fb0f89264ba160571
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add ioctl to support flushing the caches of ion
buffers from userspace.
Change-Id: I60f1daf0eef09e1307242bb3fd0ce4aef374a111
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add a proper IS_CACHED macro for detecting whether or not
flags indicated a cached mapping.
Change-Id: I2a7e130bd185d6b0bcb4b11593420b5888937880
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add explicit support for cached and uncached mappings. Functions
now describe whether mappings will be cached or uncached.
Change-Id: I3f0540c0486b134d7bc610480a3f72350337e5b1
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add infrastructure for supporting ion carveout heaps.
The memory type should be specified in the board file using
mach/ion.h. The ion platform driver will be responsible for
allocating the correct memory.
Change-Id: Id70ed1fd799f9a5a16ff971b18d0e868bc09d875
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add platform driver for msm specific ion devices
Change-Id: I8f5f2c135c667ef1ff2504306ffedc295553efe0
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Add get_ashmem_file and put_ashmem_file routines in ashmem driver to get
and return file references to ashmem file from within the kernel.
Change-Id: Ifbb54f7c1aab90f6d656a10a3c40ca2b65ceb89a
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Flush routines are required by msm architecture to properly
flush the cache based on cache architure.
Change-Id: Ic427a7393eccda794d681401fa7e3eb6807b0f0f
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
In order to allow drivers to cleanly handled teardown we need to allow them
to cancel pending async waits. To do this cleanly, we move allocation of
sync_fence_waiter to the driver calling sync_async_wait().
Change-Id: Ifcd95648be6ec07026d67f810070a4310f099989
Signed-off-by: Erik Gilling <konkers@android.com>
This patch adds an interface to return and sg_table given a
valid ion handle.
Change-Id: Icd948c60c1af0a4279f337bcd591cd39b46325e8
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Ion now uses dma-buf file descriptors to share
buffers with userspace. Ion becomes a dma-buf
exporter and any driver that can import dma-bufs
can now import ion file descriptors.
Change-Id: Ia04d6d72fb301dc088eb8db6576822e9260ff332
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed to this because:
- It boils down reinventing a new rather general-purpose userspace
synchronization interface. If we look at things like futexes, this
is hard to get right.
- Furthermore a lot of kernel code has to interact with this
synchronization primitive. This smells a look like the dri1 hw_lock,
a horror show I prefer not to reinvent.
- Even more fun is that multiple different subsystems would interact
here, so we have plenty of opportunities to create funny deadlock
scenarios.
I think synchronization is a wholesale different problem from data
sharing and should be tackled as an orthogonal problem.
Now we could demand that prepare/finish may only ensure cache
coherency (as Rob intended), but that runs up into the next problem:
We not only need mmap support to facilitate sw-only processing nodes
in a pipeline (without jumping through hoops by importing the dma_buf
into some sw-access only importer), which allows for a nicer
ION->dma-buf upgrade path for existing Android userspace. We also need
mmap support for existing importing subsystems to support existing
userspace libraries. And a loot of these subsystems are expected to
export coherent userspace mappings.
So prepare/finish can only ever be optional and the exporter /needs/
to support coherent mappings. Given that mmap access is always
somewhat fallback-y in nature I've decided to drop this optimization,
instead of just making it optional. If we demonstrate a clear need for
this, supported by benchmark results, we can always add it in again
later as an optional extension.
Other differences compared to Rob's RFC is the above mentioned support
for mapping a dma-buf through facilities provided by the importer.
Which results in mmap support no longer being optional.
Note that this dma-buf mmap patch does _not_ support every possible
insanity an existing subsystem could pull of with mmap: Because it
does not allow to intercept pagefaults and shoot down ptes importing
subsystems can't add some magic of their own at these points (e.g. to
automatically synchronize with outstanding rendering or set up some
special resources). I've done a cursory read through a few mmap
implementions of various subsytems and I'm hopeful that we can avoid
this (and the complexity it'd bring with it).
Additonally I've extended the documentation a bit to explain the hows
and whys of this mmap extension.
In case we ever want to add support for explicitly cache maneged
userspace mmap with a prepare/finish ioctl pair, we could specify that
userspace needs to mmap a different part of the dma_buf, e.g. the
range starting at dma_buf->size up to dma_buf->size*2. This works
because the size of a dma_buf is invariant over it's lifetime. The
exporter would obviously need to fall back to coherent mappings for
both ranges if a legacy clients maps the coherent range and the
architecture cannot suppor conflicting caching policies. Also, this
would obviously be optional and userspace needs to be able to fall
back to coherent mappings.
v2:
- Spelling fixes from Rob Clark.
- Compile fix for !DMA_BUF from Rob Clark.
- Extend commit message to explain how explicitly cache managed mmap
support could be added later.
- Extend the documentation with implementations notes for exporters
that need to manually fake coherency.
Change-Id: Ia8f2ae5d8a1b1c87ed12ca1c89d7bf2067239ee4
Cc: Rob Clark <rob.clark@linaro.org>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than requiring each platform call memblock_remove or reserve
from the board file, add this to ion
Change-Id: Ie418a692c13e9e0cfe93ecc83d253d3ce860fc83
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Switch these api's from scatterlists to sg_tables
Change-Id: I8b99e39633df009d472ce24704fa26af7bb50fa2
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Pull block layer fixes from Jens Axboe:
"A few small, but important fixes. Most of them are marked for stable
as well
- Fix failure to release a semaphore on error path in mtip32xx.
- Fix crashable condition in bio_get_nr_vecs().
- Don't mark end-of-disk buffers as mapped, limit it to i_size.
- Fix for build problem with CONFIG_BLOCK=n on arm at least.
- Fix for a buffer overlow on UUID partition printing.
- Trivial removal of unused variables in dac960."
* 'for-linus' of git://git.kernel.dk/linux-block:
block: fix buffer overflow when printing partition UUIDs
Fix blkdev.h build errors when BLOCK=n
bio allocation failure due to bio_get_nr_vecs()
block: don't mark buffers beyond end of disk as mapped
mtip32xx: release the semaphore on an error path
dac960: Remove unused variables from DAC960_CreateProcEntries()
Pull perf, x86 and scheduler updates from Ingo Molnar.
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tracing: Do not enable function event with enable
perf stat: handle ENXIO error for perf_event_open
perf: Turn off compiler warnings for flex and bison generated files
perf stat: Fix case where guest/host monitoring is not supported by kernel
perf build-id: Fix filename size calculation
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, kvm: KVM paravirt kernels don't check for CPUID being unavailable
x86: Fix section annotation of acpi_map_cpu2node()
x86/microcode: Ensure that module is only loaded on supported Intel CPUs
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched: Fix KVM and ia64 boot crash due to sched_groups circular linked list assumption
The hash size must fit both into u32 (jhash) and the max value of
size_t. The missing checking could lead to kernel crash, bug reported
by Seblu.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock before unlink, but may
cause skb traversing races:
- after URB is unlinked and the queue lock is released,
the refered skb and skb->next may be moved to done queue,
even be released
- in skb_queue_walk_safe, the next skb is still obtained
by next pointer of the last skb
- so maybe trigger oops or other problems
This patch extends the usage of entry->state to describe 'start_unlink'
state, so always holding the queue(rx/tx) lock to change the state if
the referd skb is in rx or tx queue because we need to know if the
refered urb has been started unlinking in unlink_urbs.
The other part of this patch is based on Huajun's patch:
always traverse from head of the tx/rx queue to get skb which is
to be unlinked but not been started unlinking.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: stable@kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
