1. 04 3月, 2011 4 次提交
  2. 02 3月, 2011 8 次提交
  3. 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
  4. 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
  5. 25 2月, 2011 2 次提交
  6. 24 2月, 2011 2 次提交
  7. 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
  8. 22 2月, 2011 11 次提交
  9. 21 2月, 2011 1 次提交
  10. 19 2月, 2011 6 次提交
  11. 18 2月, 2011 3 次提交