Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 18 9月, 2013 1 次提交
  3. 03 9月, 2013 1 次提交
    • M
      MIPS: R4k clock source initialization bug fix · afddce0c
      由 Maciej W. Rozycki 提交于 
      This is a fix for a bug introduced with commit
447cdf26, submitted as archived here:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20080312235002.c717dde3.yoichi_yuasa%40tripeaks.co.jp
regrettably with no further explanation.

The issue is with the CP0 Count register read erratum present on R4000 and
some R4400 processors.  If this erratum is present, then a read from this
register that happens around the time it reaches the value stored in the
CP0 Compare register causes a CP0 timer interrupt that is supposed to
happen when the values in the two registers match to be missed.  The
implication for the chips affected is the CP0 timer can be used either as
a source of a timer interrupt (a clock event) or as a source of a
high-resolution counter (a clock source), but not both at a time.

The erratum does not affect timer interrupt operation itself, because in
this case the CP0 Count register is only read while the timer interrupt
has already been raised, while high-resolution counter references happen
at random times.

Additionally some systems apparently have issues with the timer interrupt
line being routed externally and not following the usual CP0 Count/Compare
semantics.  In this case we don't want to use the R4k clock event.

We've meant to address the erratum and the timer interrupt routing issue
in time_init, however the commit referred to above broke our solution.
What we currently have is we enable the R4k clock source if the R4k clock
event initialization has succeeded (the timer is present and has no timer
interrupt routing issue) or there is no CP0 Count register read erratum.
Which gives the following boolean matrix:

clock event | count erratum => clock source
------------+---------------+--------------
     0      |       0       |      1 (OK)
     0      |       1       |      0 (bug!) -> no interference, could use
     1      |       0       |      1 (OK)
     1      |       1       |      1 (bug!) -> can't use, interference

What we want instead is to enable the R4k clock source if there is no CP0
Count register read erratum (obviously) or the R4k clock event
initialization has *failed* -- because in the latter case we won't be
using the timer interrupt anyway, so we don't care about any interference
CP0 Count reads might cause with the interrupt.  This corresponds to the
following boolean matrix:

clock event | count erratum => clock source
------------+---------------+--------------
     0      |       0       |      1
     0      |       1       |      1
     1      |       0       |      1
     1      |       1       |      0

This is implemented here, effectively reverting the problematic commit,
and a short explanation is given next to code modified so that the
rationale is known to future readers and confusion is prevented from
happening here again.

It is worth noting that mips_clockevent_init returns 0 upon success while
cpu_has_mfc0_count_bug returns 0 upon failure.  This is because the former
function returns an error code while the latter returns a boolean value.
To signify the difference I have therefore chosen to compare the result of
the former call explicitly against 0.
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5799/
      afddce0c
  5. 01 2月, 2013 1 次提交
  7. 01 11月, 2011 1 次提交
  9. 31 3月, 2011 1 次提交
  11. 14 11月, 2009 1 次提交
  13. 29 4月, 2008 2 次提交
  15. 01 4月, 2008 1 次提交
  17. 29 1月, 2008 1 次提交
  19. 07 1月, 2008 1 次提交
  21. 15 12月, 2007 1 次提交
    • R
      [MIPS] time: Delete weak definition of plat_time_init() due to gcc bug. · 4037500e
      由 Ralf Baechle 提交于 
      Frank Rowand <frank.rowand@am.sony.com> reports:

> In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot.
>
> The cause is that plat_time_init() from arch/mips/tx4927/common/
> tx4927_setup.c does not override the __weak plat_time_init() from
> arch/mips/kernel/time.c.  This is due to a compiler bug in gcc 4.1.1.  The
> bug is reported to not exist in earlier versions of gcc, and to be fixed in
> 4.1.2.  The problem is that the __weak plat_time_init() is empty and thus
> gets optimized out of existence (thus the linker is never given the option
> to replace the __weak function).

[ He meant the call to plat_time_init() from time_init() gets optimized away ]

> For more info on the gcc bug see
>
>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
>
> The attached patch is one workaround.  Another possible workaround

[ His patch adds -fno-unit-at-a-time for time.c ]

> would be to change the __weak plat_time_init() to be a non-empty
> function.

The __weak definition of plat_time_init was only ever meant to be a
migration helper to keep platforms that don't have a plat_time_init
compiling.  A few greps says that all platforms now supply their own
plat_time_init() so the weak definition is no longer needed.  So I
instead delete it.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4037500e
  23. 27 11月, 2007 2 次提交
    • R
      [MIPS] Only build r4k clocksource for systems that work ok with it. · 940f6b48
      由 Ralf Baechle 提交于 
      In particular as-is it's not suited for multicore and mutiprocessors
systems where there is on guarantee that the counter are synchronized
or running from the same clock at all.  This broke Sibyte and probably
others since the "[MIPS] Handle R4000/R4400 mfc0 from count register."
commit.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      940f6b48
    • R
      [MIPS] Handle R4000/R4400 mfc0 from count register. · 5aa85c9f
      由 Ralf Baechle 提交于 
      The R4000 and R4400 have an errata where if the cp0 count register is read
in the exact moment when it matches the compare register no interrupt will
be generated.

This bug may be triggered if the cp0 count register is being used as
clocksource and the compare interrupt as clockevent.  So a simple
workaround is to avoid using the compare for both facilities on the
affected CPUs.

This is different from the workaround suggested in the old errata documents;
at some opportunity probably the official version should be implemented
and tested.  Another thing to find out is which processor versions
exactly are affected.  I only have errata documents upto R4400 V3.0
available so for the moment the code treats all R4000 and R4400 as broken.

This is potencially a problem for some machines that have no other decent
clocksource available; this workaround will cause them to fall back to
another clocksource, worst case the "jiffies" source.
      5aa85c9f
  25. 03 11月, 2007 2 次提交
  27. 30 10月, 2007 1 次提交
  29. 23 10月, 2007 1 次提交
  31. 20 10月, 2007 2 次提交
  33. 19 10月, 2007 2 次提交
  35. 18 10月, 2007 1 次提交
  37. 17 10月, 2007 1 次提交
  39. 12 10月, 2007 7 次提交
  41. 15 9月, 2007 1 次提交
  43. 21 6月, 2007 1 次提交
  45. 15 6月, 2007 1 次提交
  47. 11 5月, 2007 1 次提交
  49. 17 2月, 2007 1 次提交
  51. 12 2月, 2007 1 次提交
  53. 09 1月, 2007 1 次提交
  55. 30 11月, 2006 2 次提交