- 01 10月, 2008 4 次提交
-
-
由 Russell King 提交于
Use 'shared device' mappings for devices, and use the standard bit combinations for Xscale3. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
There are actually only four separate implementations of set_pte_ext. Use assembler macros to insert code for these into the proc-*.S files. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 24 4月, 2008 1 次提交
-
-
由 Catalin Marinas 提交于
The proc-*.S files have the _prefetch_abort pointer placed at the end of the processor structure but the cpu-multi32.h defines it in the second position. The patch also fixes the support for XSC3 and the MMU-less CPUs (740, 7tdmi, 940, 946 and 9tdmi). Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 4月, 2008 1 次提交
-
-
由 Paul Brook 提交于
This patch adds a prefetch abort handler similar to the data abort one and renames the latter for consistency. Initial implementation by Paul Brook with some renaming by Catalin Marinas. Signed-off-by: NPaul Brook <paul@codesourcery.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 20 3月, 2008 1 次提交
-
-
由 Arnaud Patard 提交于
Some bootloaders are disabling write buffer coalescing. Enable it back under linux. Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 22 4月, 2007 1 次提交
-
-
由 Ruslan V. Sushko 提交于
Add Intel KIXRP435 Reference Platform based on IXP43x processor. Fixed after review : access to cp15 removed in identification functions, used access to global processor_id instead Signed-off-by: NVladimir Barinov <vbarinov@ru.mvista.com> Signed-off-by: NRuslan Sushko <rsushko@ru.mvista.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 24 1月, 2007 1 次提交
-
-
由 Dan Williams 提交于
cosmetic fix so iop333 is not reported as ixp46x iop333 cpuid = 0x69054210 Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 13 12月, 2006 1 次提交
-
-
由 Russell King 提交于
L_PTE_ASID is not really required to be stored in every PTE, since we can identify it via the address passed to set_pte_at(). So, create set_pte_ext() which takes the address of the PTE to set, the Linux PTE value, and the additional CPU PTE bits which aren't encoded in the Linux PTE value. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 04 12月, 2006 1 次提交
-
-
由 Lennert Buytenhek 提交于
XScale cores either have a DSP coprocessor (which contains a single 40 bit accumulator register), or an iWMMXt coprocessor (which contains eight 64 bit registers.) Because of the small amount of state in the DSP coprocessor, access to the DSP coprocessor (CP0) is always enabled, and DSP context switching is done unconditionally on every task switch. Access to the iWMMXt coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is first issued, and iWMMXt context switching is done lazily. CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will have iWMMXt support', but boards are supposed to select this config symbol by hand, and at least one pxa27x board doesn't get this right, so on that board, proc-xscale.S will incorrectly assume that we have a DSP coprocessor, enable CP0 on boot, and we will then only save the first iWMMXt register (wR0) on context switches, which is Bad. This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on might have iWMMXt support, and we will enable iWMMXt context switching if it does.' This means that with this patch, running a CONFIG_IWMMXT=n kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt state over context switches, and running a CONFIG_IWMMXT=y kernel on a non-iWMMXt capable CPU will still do DSP context save/restore. These changes should make iWMMXt work on PXA3xx, and as a side effect, enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined), as well as setting and using HWCAP_IWMMXT properly. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Acked-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 30 11月, 2006 1 次提交
-
-
由 Russell King 提交于
These files want to provide/access ELF hwcap information, so should be including asm/elf.h rather than asm/procinfo.h Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 11月, 2006 1 次提交
-
-
由 Paul Gortmaker 提交于
ARM patch 3756/1 added HWCAP_IWMMXT. This patch adds support for broadcasting that info via /proc/cpuinfo and sets it for the CPU features of the PXA270. I've booted 19rc3 on a pxa270 and confirmed that the /proc/cpuinfo shows "iwmmxt" in the Features. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 25 9月, 2006 1 次提交
-
-
由 Lennert Buytenhek 提交于
On stepping A0/A1 of the 80200, invalidating D-cache by line doesn't clear the dirty bits, which means that if we invalidate a dirty line, the dirty data can still be written back to memory later on. To work around this, dma_inv_range() on these two processors is implemented as dma_flush_range() (i.e. do a clean D-cache line before doing the invalidate D-cache line.) For this, we currently have a processor ID check in xscale_dma_inv_range(), but a better solution is to add a separate cache_fns and proc_info for A0/A1 80200. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 15 9月, 2006 1 次提交
-
-
由 Dan Williams 提交于
Patch from Dan Williams commit a6a38a66 changed the iop321 id to a value that does not work with all platforms. Change the mask to permit bit 11. Tested on an iq80321 600Mhz CRB. Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 29 7月, 2006 1 次提交
-
-
由 Lennert Buytenhek 提交于
Patch from Lennert Buytenhek The IOP 80219 xscale CPU is a stripped down version of the IOP32x. But the fact that the 80219 and IOP32x are very similar doesn't mean that they need to share a cpu table entry. It's also somewhat confusing for the end user to see the 80219 reported as an IOP32x, so this patch splits the IOP32x cpu table entry to make a separate entry for the 80219. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 7月, 2006 1 次提交
-
-
由 Nicolas Pitre 提交于
Patch from Nicolas Pitre According to the Intel PXA27x Processor Family Specification Update document (doc.nr. 280071-009) erratum E7, some care must be taken to locate the disabling and re-enabling of the MMU to the beginning of a cache line to avoid problems in some circumstances. Credits to Simon Vogl <simon.vogl@researchstudios.at> for bringing this up. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 30 6月, 2006 1 次提交
-
-
由 Russell King 提交于
On some CPUs, bit 4 of section mappings means "update the cache when written to". On others, this bit is required to be one, and others it's required to be zero. Finally, on ARMv6 and above, setting it turns on "no execute" and prevents speculative prefetches. With all these combinations, no one value fits all CPUs, so we have to pick a value depending on the CPU type, and the area we're mapping. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 29 6月, 2006 1 次提交
-
-
由 Russell King 提交于
Most MMU-based CPUs have a restriction on the setting of the data cache enable and mmu enable bits in the control register, whereby if the data cache is enabled, the MMU must also be enabled. Enabling the data cache without the MMU is an invalid combination. However, there are CPUs where the data cache can be enabled without the MMU. In order to allow these CPUs to take advantage of that, provide a method whereby each proc-*.S file defines the control regsiter value for use with nommu (with the MMU disabled.) Later on, when we add support for enabling the MMU on these devices, we can adjust the "crval" macro to also enable the data cache for nommu. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 22 3月, 2006 2 次提交
-
-
由 Russell King 提交于
asm/hardware.h is not required for the majority of processor support files, ioremap support, mm initialisation, acorn IO support, nor the debug code (which picks up its machine specific includes via debug-macros.S) Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Move the hardware PMD and PTE page table definitions from pgtable.h into pgtable-hwdef.h, and include pgtable-hwdef.h as necessary. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 2月, 2006 1 次提交
-
-
由 Nicolas Pitre 提交于
Patch from Nicolas Pitre The mini I-cache issue is valid only for kernel space since debuggers would not fly if they used user space addresses for their stubs. Signed-off-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 9月, 2005 1 次提交
-
-
由 Ben Dooks 提交于
Patch from Ben Dooks The `make buildcheck` is erroneously reporting that the .proc.info list is referencing items in the .init section as it is not itself postfixed with .init Signed-off-by: NBen Dooks <ben-linux@fluff.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 04 8月, 2005 1 次提交
-
-
由 Deepak Saxena 提交于
Patch from Deepak Saxena The XScale locking code is not something that has been validated on 2.6 and needs to be replaced with a more generic API to use with other ARMs that support locking features. Signed-off-by: NDeepak Saxena <dsaxena@plexity.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-