| Age | Commit message (Collapse) | Author |
|---|
|
module" into android-tegra-2.6.29
|
|
- switch all configurations to use native UART driver
- enable ALSA for non-Android configs
Change-Id: Ia48e5772e189f5cde349cfb26b33b9e497ad9c1c
|
|
Add audio SoC support for the NVIDIA Tegra SoC and the Harmony and
Whistler development platforms.
- single-link rpc dai driver to audio processor
- basic machine driver for harmony and whistler platforms
supports basic playback and record.
Change-Id: Ifad3b503f1bfa0000440c9473f0a932f406a7731
|
|
android-tegra-2.6.29
|
|
It is possible that one cpu will populate the flowctrl structure
while the other is waiting in a WFI. This change addresses
this race condition.
Change-Id: Ie4a37daa445d4546e02f748928870485d2f5f26b
|
|
Change-Id: Ie35fa84abe09c260827052a0facdee2e220334d4
|
|
communication between the operating system running on the AVP (ARM7) and
software running in Linux uses an RPC message-passing system called RM
Transport, implemented using shared message buffers in memory and a
hardware mailbox register.
this interface has previously been implemented in user-space; however,
in order to support Linux kernel sound drivers (e.g., ALSA), this
needs to be implemented in the kernel.
bug 624425
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
for highmem pages, flush_dcache_page must pin the kmap mapping in-place
using kmap_high_get, to ensure that the cache maintenance does not race
with another context calling kunmap_high on the same page and causing the
PTE to be zapped.
Change-Id: I607a6ff4aefff763e4e236bd4656453120ac2734
|
|
Fix logic pinmux config select
Change-Id: I49f8c399d57455c85ed373a66db6696cdd997bec
|
|
into android-tegra-2.6.29
|
|
Also Fixed a bug of ordering. Don't check for the FIFO is drained when the PIO is in flight.
Change-Id: I0a0f81a2060f7f6a87dd8e5f6593d688c1c80d08
|
|
|
|
Change-Id: I29b148aad0036239e3115f7f80e1b5e6eccd9b58
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
dsb() is inadequate to maintain coherence with DMA devices, since it
only guarantees that writes have been flushed from the CPU's store
buffers; store buffers in a non-DMA-coherent outer cache will not
be flushed.
Change-Id: Ia6082beb5d39c8bef7450e674a7077c5159268a3
|
|
memory shared with DMA devices which has been mapped bufferable
or outer-non-cacheable may be stored in a write buffer inside
the outer cache.
there was no exposed mechanism for flushing just these writebuffers
to memory (aside from abusing an outer cache maintenance operation
which implicitly performed the sync).
this change adds a sync callback to the outer_cache structure and
implements this callback for the ARM PL2x0 and PL3x0 cache controllers.
Change-Id: I6d9bd38a6f486044ade85f38bbbaba6960c4b714
|
|
The enter_power_state function needs to transfer control
to the appropriate power function (enter_lp2, enter_lp0 etc).
Change-Id: I466ec00b0e1b89e41b2b3a0402fb62d676ee6291
|
|
state" into android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
DMA." into android-tegra-2.6.29
|
|
an uninitialized PMU may return a completely random value for the
number of seconds; when this value is interpreted as number of
seconds since 1970, this can cause severe instability if the value
is >= 0x80000000UL (which is January 2038, sign-overflowing the
32b signed time_t value used in the kernel)
to work-around this issue, when the RTC driver is probed, it
performs an initial read of the PMU's time; if the value returned
would result in a negative time_t value, the PMU RTC is reset to 0.
bug 648967
Change-Id: Icee9940b5433e7e22edf98f9fcd5c7193b5c4f1f
|
|
suspend/resume APIs defined for tegra usb host
Bug 635299
Tested on : harmony. suspend/resume calls success.
Change-Id: I5dad8bc2cc524de74c2fd3260b014de4764c604c
|
|
Given the constraints of Tx DMA to only use the dword aligned buffer start
and dword aligned size, it would prudent to allocate a uncached DMA buffer
and copy the data to that buffer before the trasmit.
Main reason if Flushing L2 is not a cheap operation and the UART driver
model is having to do all the operations while holding the spin-lock
will not work.
Change-Id: I0ca14d5809258e2a62111f0a8a5e8a8053de1a34
|
|
Added support for doing readbyte, writebyte and reset Presence pulse
added new enum for supporting these operations.
By default made the ByteMode to FALSE
Addresses Bug 509729
Change-Id: Ib9bdc983eadeda97592213dec7480ad4117dbcf6
|
|
- all the EC client threads should be freezable while
going into suspend and so as the nvec keyboard thread.
bug 646208
Change-Id: I95285829b229d5e482f216507210258e05de792c
|
|
SMSC LAN9500 has dual purpose GPIO/LED pins, and by default at power-on
these are configured as GPIOs. This means that if LEDs are fitted they
won't ever light.
This patch sets them to be LED outputs for speed, duplex and
link/activity.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In xdr_partial_copy_from_skb() there is that sequence:
kaddr = kmap_atomic(*ppage, KM_SKB_SUNRPC_DATA);
[...]
flush_dcache_page(*ppage);
kunmap_atomic(kaddr, KM_SKB_SUNRPC_DATA);
Mixing flush_dcache_page() and kmap_atomic() is a bit odd,
especially since kunmap_atomic() must deal with cache issues
already. OTOH the non-highmem case must use flush_dcache_page()
as kunmap_atomic() becomes a no op with no cache maintenance.
Problem is that with highmem the implementation of kmap_atomic()
doesn't set page->virtual, and page_address(page) returns 0 in
that case. Here flush_dcache_page() calls __flush_dcache_page()
which calls __cpuc_flush_dcache_page(page_address(page)) resulting
in a kernel oops.
None of the kmap_atomic() implementations uses set_page_address().
Hence we can assume page_address() is always expected to return 0 in
that case. Let's conditionally call __cpuc_flush_dcache_page() only
when the page address is non zero, and perform that test only when
highmem is configured.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
On OMAP platforms, some people want to declare to segment up the memory
between the kernel and a separate application such that there is a hole
in the middle of the memory as far as Linux is concerned. However,
they want to be able to mmap() the hole.
This currently causes problems, because update_mmu_cache() thinks that
there are valid struct pages for the "hole". Fix this by making
pfn_valid() slightly more expensive, by checking whether the PFN is
contained within the meminfo array.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Khasim Syed Mohammed <khasim@ti.com>
|
|
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Currently, highmem is selectable, and you can request an increased
vmalloc area. However, none of this has any effect on the memory
layout since a patch in the highmem series was accidentally dropped.
Moreover, even if you did want highmem, all memory would still be
registered as lowmem, possibly resulting in overflow of the available
virtual mapping space.
The highmem boundary is determined by the highest allowed beginning
of the vmalloc area, which depends on its configurable minimum size
(see commit 60296c71f6c5063e3c1f1d2619ca0b60940162e7 for details on
this).
We should create mappings and initialize bootmem only for low memory,
while the zone allocator must still be told about highmem.
Currently, memory nodes which are completely located in high memory
are not supported. This is not a huge limitation since systems
relying on highmem support are unlikely to have discontiguous memory
with large holes.
[ A similar patch was meant to be merged before commit 5f0fbf9ecaf3
and be available in Linux v2.6.30, however some git rebase screw-up
of mine dropped the first commit of the series, and that goofage
escaped testing somehow as well. -- Nico ]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
|
|
when 2468311edda7e91b9e9ece9a05e4d2337217a9d0 was cherry-picked,
the merge wasn't resolved correctly, and left a dangling MODULES_END
declaration. with CONFIG_HIGHMEM enabled, this caused numerous
compiler warnings
Change-Id: If401e4591f12316df3db33db4dd7dca03a10b9d4
|
|
Here it is... HIGHMEM for the ARM architecture. :-)
If you don't have enough ram for highmem pages to be allocated and still
want to test this, then the cmdline option "vmalloc=" can be used with
a value large enough to force the highmem threshold down.
Successfully tested on a Marvell DB-78x00-BP Development Board with
2 GB of RAM.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
|
x86 has debug_kmap_atomic_prot() which is error checking function for
kmap_atomic. It is usefull for the other architectures, although it needs
CONFIG_TRACE_IRQFLAGS_SUPPORT.
This patch exposes it to the other architectures.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Most ARM machines have a non IO coherent cache, meaning that the
dma_map_*() set of functions must clean and/or invalidate the affected
memory manually before DMA occurs. And because the majority of those
machines have a VIVT cache, the cache maintenance operations must be
performed using virtual
addresses.
When a highmem page is kunmap'd, its mapping (and cache) remains in place
in case it is kmap'd again. However if dma_map_page() is then called with
such a page, some cache maintenance on the remaining mapping must be
performed. In that case, page_address(page) is non null and we can use
that to synchronize the cache.
It is unlikely but still possible for kmap() to race and recycle the
virtual address obtained above, and use it for another page before some
on-going cache invalidation loop in dma_map_page() is done. In that case,
the new mapping could end up with dirty cache lines for another page,
and the unsuspecting cache invalidation loop in dma_map_page() might
simply discard those dirty cache lines resulting in data loss.
For example, let's consider this sequence of events:
- dma_map_page(..., DMA_FROM_DEVICE) is called on a highmem page.
--> - vaddr = page_address(page) is non null. In this case
it is likely that the page has valid cache lines
associated with vaddr. Remember that the cache is VIVT.
--> for (i = vaddr; i < vaddr + PAGE_SIZE; i += 32)
invalidate_cache_line(i);
*** preemption occurs in the middle of the loop above ***
- kmap_high() is called for a different page.
--> - last_pkmap_nr wraps to zero and flush_all_zero_pkmaps()
is called. The pkmap_count value for the page passed
to dma_map_page() above happens to be 1, so the page
is unmapped. But prior to that, flush_cache_kmaps()
cleared the cache for it. So far so good.
- A fresh pkmap entry is assigned for this kmap request.
The Murphy law says this pkmap entry will eventually
happen to use the same vaddr as the one which used to
belong to the other page being processed by
dma_map_page() in the preempted thread above.
- The kmap_high() caller start dirtying the cache using the
just assigned virtual mapping for its page.
*** the first thread is rescheduled ***
- The for(...) loop is resumed, but now cached
data belonging to a different physical page is
being discarded !
And this is not only a preemption issue as ARM can be SMP as well,
making the above scenario just as likely. Hence the need for some kind
of pkmap page pinning which can be used in any context, primarily for
the benefit of dma_map_page() on ARM.
This provides the necessary interface to cope with the above issue if
ARCH_NEEDS_KMAP_HIGH_GET is defined, otherwise the resulting code is
unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Reviewed-by: MinChan Kim <minchan.kim@gmail.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
|
|
This is the minimum fixmap interface expected to be implemented by
architectures supporting highmem.
We have a second level page table already allocated and covering
0xfff00000-0xffffffff because the exception vector page is located
at 0xffff0000, and various cache tricks already use some entries above
0xffff0000. Therefore the PTEs covering 0xfff00000-0xfffeffff are free
to be used.
However the XScale cache flushing code already uses virtual addresses
between 0xfffe0000 and 0xfffeffff.
So this reserves the 0xfff00000-0xfffdffff range for fixmap stuff.
The Documentation/arm/memory.txt information is updated accordingly,
including the information about the actual top of DMA memory mapping
region which didn't match the code.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
|
|
the initial cache writeback for highmem pages in the nvos page allocator
had accidentally shadowed the variable used to store the kernel address,
so the page was never unmapped.
this caused a quick exhaustion of the kmap area during Android bootup.
Change-Id: I6e27b7b7f75162652f32296784b53cbdbdc502c4
|
|
nvmap-allocated memory is used primarily by DMA devices, and the cost
of L2 maintenance generally greatly outweighs the benefit of caching
the (mostly streaming) accesses.
a reserved region of the kernel's virtual address space (NVMAP_BASE to
NVMAP_BASE+NVMAP_SIZE) is used by nvmap as a temporary mapping area for
all operations (cache maintenance, read, write) on memory handles is
perfomed by mapping each page into the nvmap aperture with the same
cache attributes as other active mappings.
this change greatly improves the performance of drawing the drawer
and web pages in Android, since the primary bottleneck in both cases
has been the L2 cache maintenance operations (which no longer exist)
additionally, when cache writebacks are requested on large regions
(currently defined as >= 3 pages), the entire L1 data cache is flushed,
to avoid the loop costs of per-line operations.
Change-Id: I37e07c86eb316811f63e7200d52667debf4b7aa7
|
|
drivers which perform DMA mapping can optimize necessary cache
maintenance by using a full-cache clean or flush rather than
looping over large regions line-by-line.
there was no previous full-cache operation other than
flush_kern_cache_all, and this operation both invalidates the
data cache (not always necessary) and invalidates the instruction
cache, both of which unnecessarily hurt performance on CPUs with
Harvard caches
Change-Id: If71015525457e9e7e481fc2afcdc76bc3fa8f8f4
|
|
rewrite page-allocation routines to integrate with highmem correctly,
and to allow for inner cached outer non-cached mappings of the regions
change the allocation pool from GFP_ATOMIC to kernel & highmem pages,
and disable the debug printout when page allocation fails
bug 641308
Change-Id: I82100c980bc0b2aa390aa6b1fb93d337f98f134a
|
|
Warmboot requires that relevant state be saved in the scratch registers.
The kernel appropriately populates all required scratch registers
with the exception of the sdram parameters (done by the bootloader).
Change-Id: I6ea1848e669acf35f9021c9c2f4c0c3e3cbb4181
|
|
use tabs rather than spaces in nvmap.c, decompose nvmap_rw_handle to fit
within 80 columns
Change-Id: Ie29072ad9f32de4a0d418f487b73c0826637f551
|
|
For streaming-style operations (e.g., software rendering of graphics
surfaces shared with non-coherent DMA devices), the cost of performing
L2 cache maintenance can exceed the benefit of having the larger cache
(this is particularly true for OUTER_CACHE configurations like the ARM
PL2x0).
This change uses the currently-unused mapping 5 (TEX[0]=1, C=0, B=1)
in the ARMv7 TRE table as an inner-writeback-write-allocate, outer
non-cacheable memory type, so that this mapping will be available to
clients which will benefit from the reduced L2 maintenance.
Change-Id: Ifd88f6df3e98ff3f8fbe95283891b9a9b1070c6b
|
|
|
