Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 11月, 2012 1 次提交
  3. 14 9月, 2012 1 次提交
  5. 19 7月, 2012 1 次提交
  7. 07 7月, 2012 1 次提交
  9. 17 5月, 2012 1 次提交
  11. 29 3月, 2012 1 次提交
  13. 20 3月, 2012 1 次提交
  15. 08 12月, 2011 1 次提交
  17. 20 10月, 2011 1 次提交
  19. 26 7月, 2011 1 次提交
    • K
      MIPS: Add SYNC after cacheflush · d0023c4a
      由 Kevin Cernekee 提交于 
      On processors with deep write buffers, it is likely that many cycles
will pass between a CACHE instruction and the time the data actually
gets written out to DRAM.  Add a SYNC instruction to ensure that the
buffers get emptied before the flush functions return.

Actual problem seen in the wild:

1) dma_alloc_coherent() allocates cached memory

2) memset() is called to clear the new pages

3) dma_cache_wback_inv() is called to flush the zero data out to memory

4) dma_alloc_coherent() returns an uncached (kseg1) pointer to the
freshly allocated pages

5) Caller writes data through the kseg1 pointer

6) Buffered writeback data finally gets flushed out to DRAM

7) Part of caller's data is inexplicably zeroed out

This patch adds SYNC between steps 3 and 4, which fixed the problem.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: 
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d0023c4a
  21. 19 5月, 2011 1 次提交
  23. 11 5月, 2011 1 次提交
    • R
      MIPS: c-r4k: Fix GCC 4.6.0 build error · 71271aab
      由 Ralf Baechle 提交于 
        CC      arch/mips/mm/c-r4k.o
arch/mips/mm/c-r4k.c: In function 'probe_scache':
arch/mips/mm/c-r4k.c:1078:6: error: variable 'tmp' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

Older GCC versions didn't warn about the unused variable tmp because it was
getting initialized.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      71271aab
  25. 06 4月, 2011 1 次提交
  27. 30 10月, 2010 2 次提交
  29. 25 6月, 2009 1 次提交
  31. 17 6月, 2009 1 次提交
  33. 14 5月, 2009 1 次提交
  35. 30 3月, 2009 1 次提交
    • M
      MIPS: Alchemy: unify CPU model constants. · 270717a8
      由 Manuel Lauss 提交于 
      This patch removes the various CPU_AU1??? model constants in favor of
a single CPU_ALCHEMY one.

All currently existing Alchemy models are identical in terms of cpu
core and cache size/organization.  The parts of the mips kernel which
need to know the exact CPU revision extract it from the c0_prid register
already; and finally nothing else in-tree depends on those any more.

Should a new variant with slightly different "company options" and/or
"processor revision" bits in c0_prid appear, it will be supported
immediately (minus an exact model string in cpuinfo).
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      270717a8
  37. 24 3月, 2009 1 次提交
  39. 31 1月, 2009 1 次提交
  41. 06 9月, 2008 1 次提交
  43. 26 6月, 2008 1 次提交
  45. 16 6月, 2008 2 次提交
  47. 29 4月, 2008 2 次提交
  49. 08 4月, 2008 1 次提交
  51. 12 3月, 2008 1 次提交
  53. 20 2月, 2008 1 次提交
    • R
      [MIPS] Handle I-cache coherency in flush_cache_range() · 2eaa7ec2
      由 Ralf Baechle 提交于 
      So far flush_cache_range() did't consider the I-cache largely because it
did rarely ever matter to real world code.  This was working primarily
because normally code and data are don't share the same pages - with the
exception of MIPS16 code which uses address constants embedded between
the code.   The following sequence of events may break the code:

 o MIPS16 executable being loaded
 o dynamic linker relocates the address constants embedded into the code:
 o   Uses mprotect(2) to make code pages PROT_READ|PROT_WRITE
 o   Performs the actual relocations by writing to the pages which likely
     are COW.  Because no PROT_EXEC is set I-cache coherence will not be
     considered.
 o   Uses mprotect(2) to switch code pages back to PROT_READ|PROT_EXEC.
     This results in a call to flush_cache_range() which also does not
     consider I-caches.
 o => executing the page just having been relocated may now result in the
   I-cache getting refilled with stale data from memory.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2eaa7ec2
  55. 03 2月, 2008 1 次提交
  57. 29 1月, 2008 4 次提交
  59. 16 11月, 2007 1 次提交
    • R
      [MIPS] Sibyte: resurrect old cache hack. · a754f708
      由 Ralf Baechle 提交于 
      The recent switch of the Sibyte SOCs from the processor specific cache
managment code in c-sb1.c to c-r4k.c lost this old hack

    [MIPS] Hack for SB1 cache issues

    Removing flush_icache_page a while ago broke SB1 which was using an empty
    flush_data_cache_page function.  This glues things well enough so a more
    efficient but also more intrusive solution can be found later.
Signed-Off-By: NThiemo Seufer <ths@networkno.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

in the hope it was no longer needed.  As it turns it still is so resurrect
it until there is a better solution.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a754f708
  61. 30 10月, 2007 1 次提交
    • R
      [MIPS] MT: Fix bug in multithreaded kernels. · a76ab5c1
      由 Ralf Baechle 提交于 
      When GDB writes a breakpoint into address area of inferior process the
kernel needs to invalidate the modified memory in the inferior which
is done by calling flush_cache_page which in turns calls
r4k_flush_cache_page and local_r4k_flush_cache_page for VSMP or SMTC
kernel via r4k_on_each_cpu().

As the VSMP and SMTC SMP kernels for 34K are running on a single shared
caches it is possible to get away without interprocessor function calls.
This optimization is implemented in r4k_on_each_cpu, so
local_r4k_flush_cache_page is only ever called on the local CPU.

This is where the following code in local_r4k_flush_cache_page() strikes:

        /*
         * If ownes no valid ASID yet, cannot possibly have gotten
         * this page into the cache.
         */
        if (cpu_context(smp_processor_id(), mm) == 0)
                return;

On VSMP and SMTC had a function of cpu_context() for each CPU(TC).

So in case another CPU than the CPU executing local_r4k_cache_flush_page
has not accessed the mm but one of the other CPUs has there may be data
to be flushed in the cache yet local_r4k_cache_flush_page will falsely
return leaving the I-cache inconsistent for the breakpoint.

While the issue was discovered with GDB it also exists in
local_r4k_flush_cache_range() and local_r4k_flush_cache().

Fixed by introducing a new function has_valid_asid which on MT kernels
returns true if a mm is active on any processor in the system.

This is relativly expensive since for memory acccesses in that loop
cache misses have to be assumed but it seems the most viable solution
for 2.6.23 and older -stable kernels.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a76ab5c1
  63. 17 10月, 2007 1 次提交
  65. 12 10月, 2007 2 次提交