Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 153
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 28 9月, 2006 7 次提交
  3. 27 9月, 2006 7 次提交
  5. 25 9月, 2006 4 次提交
  7. 20 9月, 2006 2 次提交
  9. 15 9月, 2006 1 次提交
  11. 07 9月, 2006 1 次提交
  13. 03 9月, 2006 1 次提交
    • G
      [ARM] 3762/1: Fix ptrace cache coherency bug for ARM1136 VIPT nonaliasing Harvard caches · a188ad2b
      由 George G. Davis 提交于 
      Patch from George G. Davis

Resolve ARM1136 VIPT non-aliasing cache coherency issues observed when
using ptrace to set breakpoints and cleanup copy_{to,from}_user_page()
while we're here as requested by Russell King because "it's also far
too heavy on non-v6 CPUs".

NOTES:

1. Only access_process_vm() calls copy_{to,from}_user_page().
2. access_process_vm() calls get_user_pages() to pin down the "page".
3. get_user_pages() calls flush_dcache_page(page) which ensures cache
   coherency between kernel and userspace mappings of "page".  However
   flush_dcache_page(page) may not invalidate I-Cache over this range
   for all cases, specifically, I-Cache is not invalidated for the VIPT
   non-aliasing case.  So memory is consistent between kernel and user
   space mappings of "page" but I-Cache may still be hot over this
   range.  IOW, we don't have to worry about flush_cache_page() before
   memcpy().
4. Now, for the copy_to_user_page() case, after memcpy(), we must flush
   the caches so memory is consistent with kernel cache entries and
   invalidate the I-Cache if this mm region is executable.  We don't
   need to do anything after memcpy() for the copy_from_user_page()
   case since kernel cache entries will be invalidated via the same
   process above if we access "page" again.  The flush_ptrace_access()
   function (borrowed from SPARC64 implementation) is added to handle
   cache flushing after memcpy() for the copy_to_user_page() case.
Signed-off-by: NGeorge G. Davis <gdavis@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a188ad2b
  15. 28 8月, 2006 1 次提交
  17. 29 7月, 2006 3 次提交
  19. 03 7月, 2006 5 次提交
  21. 02 7月, 2006 2 次提交
  23. 01 7月, 2006 2 次提交
  25. 30 6月, 2006 2 次提交
    • R
      [ARM] Add section support to ioremap · ff0daca5
      由 Russell King 提交于 
      Allow section mappings to be setup using ioremap() and torn down
with iounmap().  This requires additional support in the MM
context switch to ensure that mappings are properly synchronised
when mapped in.

Based an original implementation by Deepak Saxena, reworked and
ARMv6 support added by rmk.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ff0daca5
    • R
      [ARM] Set bit 4 on section mappings correctly depending on CPU · 8799ee9f
      由 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>
      8799ee9f
  27. 29 6月, 2006 2 次提交
    • A
      [ARM] 3675/2: Preparing for AT91SAM926 support · 8fc5ffa0
      由 Andrew Victor 提交于 
      Patch from Andrew Victor

This prepares the way for adding support for the new Atmel AT91SAM926x
processors.

Major changes:
- Rename time.c to at91rm9200_time.c
- Rename common.c to at91rm9200.c
- Introduce ARCH_AT91, of which ARCH_AT91RM9200, ARCH_AT91SAM9260 and
ARCH_AT91SAM9261 are dependent.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8fc5ffa0
    • R
      [ARM] nommu: provide a way for correct control register value selection · 22b19086
      由 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>
      22b19086