| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
android-tegra-2.6.29
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
cases" into android-tegra-2.6.29
|
|
- setting set_freezable_with_signal at the start of the thread
- replaced NvOsSemaphoreWaitTimeout by wait_event_freezable_timeout
- marked a shutdown variable and signalled the semaphore before joining
with the thread
Change-Id: I06a11848cc20498b57387a0c4bb55c330065768f
|
|
Updated MAX8907B power enable (PWREN) input configuration for the new
silicon revision.
Change-Id: Ia13f518d34084ba5c1554c02d8da3d3c8fe4fd70
|
|
into android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
android-tegra-2.6.29
|
|
Bug 631316: USB charging support in Android Eclair
- Added code in Max8907bSetChargingCurrent().
- Cleaned up end-of-line spaces.
Change-Id: I8aaee731d74713d29ecd167da29a321abadc20fc
|
|
The Offset calculation was done wrong while doing a read operation.
This has been fixed now.
The total size of the EPROM is being retrieved from the odm query, this
value may vary for vendors.
Addresses Bug 509729
|
|
* changes:
tegra: Fix buges in DMA mode for high speed UART trasmit.
|
|
Mix of hardcoded values and enums caused the code to take unexepcted paths causing Tx failures.
Tested with BT scanning of devices.
Change-Id: Ic82f1749304262487a4bf0d2e42e5edeadcf360c
|
|
Save additional state for mc,apb,apbchan,misc,intc blocks prior
to shutdown. Changes are currently inactive.
Change-Id: I4563d5334ea5b483a5f69858c7f0d3fe2a5ee349
|
|
Clipped CPU voltage to PMU voltage range (maybe necessary for really
fast parts with very low nominal voltage).
Change-Id: I2483699cca0f0f5ba3001e75655dcb66d65275c7
|
|
* changes:
tegra RM: adjusted DVFS thresholds.
|
|
* changes:
tegra2 rtc: date/time non-persistent on boards
|
|
* changes:
tegra power: Add save/restore code for ClockReset block.
|
|
Multi-stage Changes are as follows:
Change1:
1) TPS6586x PMU RTC(harmony) cannot store more than 34 years duration.
Hence, RTC driver has been modified to use year 2009 as reference
instead of the year 1970(used in linux by default). Change in
tps6586x rtc implementation.
Issue was Fixed in Bug 621031 earlier and checked into p4 by modifying
tegra rtc driver. We are using a different approach now by only
modifying tps6586x rtc driver. This way rtc drivers for other PMU
like max8907b which can store as much 9999 years in RTC do not need
to change.
2) MAX8907B PMU RTC(whistler) driver was not storing day/month/year data
earlier. Further, on every boot the RTC was being cleared. Fixed this
in file max8907b_rtc.c
Implementation specific to linux as uses library functions: mktime and
rtc_time_to_tm
3) MAX8907B PMU I2C read API implementation was not reading 4th byte.
Changed this as DD, MM, YY1, YY2 information is being read now.
Changed max8907b_i2c.c Further, changes are as follows:
Change2:
1) TPS6586x PMU RTC(harmony) driver modified to select crystal oscillator
as source for RTC. After this change find that RTC counts even when
harmony is powered off.
2) MAX8907B PMU RTC(whistler) driver modified to incorporate review
comments
a) renamed macro SHIFT_TO_2009 as OFFSET_BASE_YEAR
b) used a macro for BCD to decimal conversion for better readability.
Change set 1 was committed but was reverted because of bugs 645312
and 645286. Further tests showed that if the date is set before
testing gallery app the issue is not seen. Trying to re-submit
reverted checkin for change1 along with change2 as a new change.
Change3:
a) decimal to bcd expresssion converted to macro
b) corrected spelling
Bug 625990 : [Firefly2/Harmony] Date & Time is not persisting after reboot
Tested on : Harmony + whistler. Date/time persists.
Note: Whistler rechargable battery needs to be charged to 2.4V for
RTC data to persist. Harmony has non-rechargable battery.
Change-Id: Icc543261096ee4c89cc1e394e2b3868ac370f8e9
|
