Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 7月, 2009 6 次提交
    • P
      OMAP2/3 clock: split, rename omap2_wait_clock_ready() · 72350b29
      由 Paul Walmsley 提交于 
      Some OMAP2/3 hardware modules have CM_IDLEST attributes that are not
handled by the current omap2_wait_clock_ready() code.  In preparation
for patches that fix the unusual devices, rename the function
omap2_wait_clock_ready() to omap2_wait_module_ready() and split it
into three parts:

1. A clkops-specific companion clock return function (by default,
   omap2_clk_dflt_find_companion())

2. A clkops-specific CM_IDLEST register address and bit shift return
   function (by default, omap2_clk_dflt_find_idlest())

3. Code to wait for the CM to indicate that the module is ready
   (omap2_cm_wait_idlest())

Clocks can now specify their own custom find_companion() and find_idlest()
functions; used in subsequent patches.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      72350b29
    • R
      OMAP3 SDRC: Move the clk stabilization delay to the right place · df56556e
      由 Rajendra Nayak 提交于 
      The clock stabilization delay post a M2 divider change is needed
even before a SDRC interface clock re-enable and not only before
jumping back to SDRAM.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      df56556e
    • R
      OMAP3 SDRC: Fix freeze when scaling CORE dpll to < 83Mhz · 8ff120e5
      由 Rajendra Nayak 提交于 
      This patch fixes a bug in the CORE dpll scaling sequence which was
errouneously clearing some bits in the SDRC DLLA CTRL register and
hence causing a freeze.  The issue was observed only on platforms
which scale CORE dpll to < 83Mhz and hence program the DLL in fixed
delay mode.

Issue reported by Limei Wang <E12499@motorola.com>, with debugging
assistance from Richard Woodruff <r-woodruff2@ti.com> and Girish
Ghongdemath <girishsg@ti.com>.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Limei Wang <E12499@motorola.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Girish Ghongdemath <girishsg@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
[paul@pwsan.com: updated patch description to include collaboration credits]
      8ff120e5
    • P
      OMAP2/3 SDRC: don't set SDRC_POWER.PWDENA on boot · 75f251e3
      由 Paul Walmsley 提交于 
      Stop setting SDRC_POWER.PWDENA on boot.  There is a nasty erratum
(34xx erratum 1.150) that can cause memory corruption if PWDENA is
enabled.

Based originally on a patch from Samu P. Onkalo <samu.p.onkalo@nokia.com>.

Tested on BeagleBoard rev C2.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Samu P. Onkalo <samu.p.onkalo@nokia.com>
      75f251e3
    • J
      OMAP3: Setup MUX settings for SDRC CKE signals · 9fb97412
      由 Jean Pihet 提交于 
      This patches ensures the MUX settings are correct for the SDRC
CKE signals to SDRAM. This allows the self-refresh to work when
2 chip-selects are in use.

A warning is thrown away in case the initial muxing is incorrect,
in order to track faulty or old-dated bootloaders.
Note: The CONFIG_OMAP_MUX and CONFIG_OMAP_MUX_WARNINGS options
must be enabled for the mux code to have effect.
Signed-off-by: NJean Pihet <jpihet@mvista.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9fb97412
    • J
      OMAP3 SDRC: add support for 2 SDRAM chip selects · 58cda884
      由 Jean Pihet 提交于 
      Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
SDRAM parts connected to the SDRC.

This patch adds the following:
- add a new argument of type omap_sdrc_params struct*
to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw
- add the SDRC 2nd CS registers offsets defines
- adapt the sram sleep code to configure the SDRC for the 2nd CS

Note: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registers

Tested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).
Signed-off-by: NJean Pihet <jpihet@mvista.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      58cda884
  3. 23 7月, 2009 33 次提交
  5. 22 7月, 2009 1 次提交
    • L
      fbmon: work around compiler bug in gcc-2.4.2 · 3730793d
      由 Linus Torvalds 提交于 
      There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent
he loop counter is of type 'unsigned char' and it should count to 128.

The compiler will incorrectly decide that a trivial loop like this:

	unsigned char i, ...

	for (i = 0; i < 128; i++) {
		..

is endless, and will compile it to a single instruction that just
branches to itself.

This was triggered by the addition of '-fno-strict-overflow', and we
could play games with compiler versions and go back to '-fwrapv'
instead, but the trivial way to avoid it is to just make the loop
induction variable be an 'int' instead.

Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure
for digging through assembler differences and finding it.
Reported-and-tested-by: NKrzysztof Oledzki <olel@ans.pl>
Found-by: NTroy Moure <twmoure@szypr.net>
Gcc-bug-acked-by: NIan Lance Taylor <iant@google.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3730793d