Skip to content

cloud-kernel
cloud-kernel

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

通知 163
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 03 3月, 2011 19 次提交
  3. 02 3月, 2011 6 次提交
  5. 28 2月, 2011 1 次提交
    • D
      x86: Use u32 instead of long to set reset vector back to 0 · 299c5696
      由 Don Zickus 提交于 
      A customer of ours, complained that when setting the reset
vector back to 0, it trashed other data and hung their box.
They noticed when only 4 bytes were set to 0 instead of 8,
everything worked correctly.

Mathew pointed out:

 |
 | We're supposed to be resetting trampoline_phys_low and
 | trampoline_phys_high here, which are two 16-bit values.
 | Writing 64 bits is definitely going to overwrite space
 | that we're not supposed to be touching.
 |

So limit the area modified to u32.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Cc: <stable@kernel.org>
LKML-Reference: <1297139100-424-1-git-send-email-dzickus@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      299c5696
  7. 26 2月, 2011 1 次提交
    • S
      omap4: prcm: Fix the CPUx clockdomain offsets · 51c404b2
      由 Santosh Shilimkar 提交于 
      CPU0 and CPU1 clockdomain is at the offset of 0x18 from the LPRM base.
The header file has set it wrongly to 0x0. Offset 0x0 is for CPUx power
domain control register

Fix the same.

The autogen scripts is fixed thanks to Benoit Cousson

With the old value, the clockdomain code would access the
*_PWRSTCTRL.POWERSTATE field when it thought it was accessing the
*_CLKSTCTRL.CLKTRCTRL field.  In the worst case, this could cause
system power management to behave incorrectly.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: added second paragraph to commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      51c404b2
  9. 25 2月, 2011 2 次提交
  11. 24 2月, 2011 2 次提交
  13. 23 2月, 2011 1 次提交
    • J
      OMAP2/3: clock: fix fint calculation for DPLL_FREQSEL · ea68c00e
      由 John Ogness 提交于 
      In OMAP35X TRM Rev 2010-05 Figure 7-18 "DPLL With EMI Reduction
Feature", it is shown that the internal frequency is calculated by
CLK_IN/(N+1). However, the value passed to _dpll_test_fint() is
already "N+1" since Linux is using the values to divide by. In the
technical reference manual, "N" is referring to the divider's register
value (0-127).

During power management testing, it was observed that programming the
wrong jitter correction value can cause the system to become unstable
and eventually crash.
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
[paul@pwsan.com: added second paragraph to commit message]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      ea68c00e
  15. 22 2月, 2011 8 次提交