Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 5月, 2009 1 次提交
  3. 26 5月, 2009 9 次提交
  5. 19 5月, 2009 2 次提交
  7. 18 5月, 2009 3 次提交
    • P
      [ARM] mach-l7200: fix spelling of SYS_CLOCK_OFF · 8190b37f
      由 Pavel Roskin 提交于 
      Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8190b37f
    • M
      [ARM] Double check memmap is actually valid with a memmap has unexpected holes V2 · eb33575c
      由 Mel Gorman 提交于 
      pfn_valid() is meant to be able to tell if a given PFN has valid memmap
associated with it or not. In FLATMEM, it is expected that holes always
have valid memmap as long as there is valid PFNs either side of the hole.
In SPARSEMEM, it is assumed that a valid section has a memmap for the
entire section.

However, ARM and maybe other embedded architectures in the future free
memmap backing holes to save memory on the assumption the memmap is never
used. The page_zone linkages are then broken even though pfn_valid()
returns true. A walker of the full memmap must then do this additional
check to ensure the memmap they are looking at is sane by making sure the
zone and PFN linkages are still valid. This is expensive, but walkers of
the full memmap are extremely rare.

This was caught before for FLATMEM and hacked around but it hits again for
SPARSEMEM because the page_zone linkages can look ok where the PFN linkages
are totally screwed. This looks like a hatchet job but the reality is that
any clean solution would end up consumning all the memory saved by punching
these unexpected holes in the memmap. For example, we tried marking the
memmap within the section invalid but the section size exceeds the size of
the hole in most cases so pfn_valid() starts returning false where valid
memmap exists. Shrinking the size of the section would increase memory
consumption offsetting the gains.

This patch identifies when an architecture is punching unexpected holes
in the memmap that the memory model cannot automatically detect and sets
ARCH_HAS_HOLES_MEMORYMODEL. At the moment, this is restricted to EP93xx
which is the model sub-architecture this has been reported on but may expand
later. When set, walkers of the full memmap must call memmap_valid_within()
for each PFN and passing in what it expects the page and zone to be for
that PFN. If it finds the linkages to be broken, it assumes the memmap is
invalid for that PFN.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      eb33575c
    • R
      [ARM] realview: fix broadcast tick support · ee348d5a
      由 Russell King 提交于 
      Having discussed broadcast tick support with Thomas Glexiner, the
broadcast tick devices should be registered with a higher rating
than the global tick device, and it should have the ONESHOT and
PERIODIC feature flags set.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NThomas Glexiner <tglx@linutronix.de>
      ee348d5a
  9. 17 5月, 2009 4 次提交
  11. 16 5月, 2009 3 次提交
  13. 15 5月, 2009 8 次提交
  15. 13 5月, 2009 10 次提交
    • P
      OMAP2xxx clock: rename clk_init_one() to clk_preinit() · 79716870
      由 Paul Walmsley 提交于 
      Rename clk_init_one() to clk_preinit() to distinguish its function
from clk_init() and the individual struct clk init functions.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      79716870
    • A
      OMAP3 clock: lessen amount of noisy messages · 0db4e825
      由 Artem Bityutskiy 提交于 
      On our system we see the following messages:

Disabling unused clock "gpt2_ick"
Disabling unused clock "gpt3_ick"
Disabling unused clock "gpt4_ick"
Disabling unused clock "gpt5_ick"
...

The messages have KERN_INFO level and if you have serial
console, they normally go there. I do not think it is good
idea to print that much stuff there. Moreover, messages
are not properly prefixed and for mortals it is not
immeadietly clear where they come from.

Let's give them debugging level instead.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
[paul@pwsan.com: trimmed debugging output in patch description]
      0db4e825
    • P
      OMAP3 clock: use pr_debug() rather than pr_info() in some clock change code · b7aee4bf
      由 Paul Walmsley 提交于 
      The CORE DPLL M2 frequency change code should use pr_debug(), not
pr_info(), for its debug messages.  Same with
omap2_clksel_round_rate_div().  While here, convert a few printk(KERN_ERR ..
into pr_err().
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b7aee4bf
    • P
      OMAP3 clock: only unlock SDRC DLL if SDRC clk < 83MHz · 4519c2bf
      由 Paul Walmsley 提交于 
      According to the 34xx TRM Rev. K section 11.2.4.4.11.1 "Purpose of the
DLL/CDL Module," the SDRC delay-locked-loop can be locked at any SDRC
clock frequency from 83MHz to 166MHz.  CDP code unconditionally
unlocked the DLL whenever shifting to a lower SDRC speed, but this
seems unnecessary and error-prone, as the DLL is no longer able to
compensate for process, voltage, and temperature variations.  Instead,
only unlock the DLL when the SDRC clock rate would be less than 83MHz.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      4519c2bf
    • P
      OMAP3 SRAM: renumber registers to make space for argument passing · b2abb271
      由 Paul Walmsley 提交于 
      Renumber registers in omap3_sram_configure_core_dpll() assembly code to
make space for additional parameters.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b2abb271
    • P
      OMAP3 SDRC: initialize SDRC_POWER at boot · 98cfe5ab
      由 Paul Walmsley 提交于 
      Initialize SDRC_POWER to a known-good setting when the kernel boots.
Necessary since some bootloaders don't initialize SDRC_POWER properly.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      98cfe5ab
    • P
      OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency change · fa0406a8
      由 Paul Walmsley 提交于 
      Clear the SDRC_POWER.PWRENA bit before putting the SDRAM into self-refresh
mode.  This prevents the SDRC from attempting to power off the SDRAM,
which can cause the system to hang.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      fa0406a8
    • P
      OMAP3 clock: add interconnect barriers to CORE DPLL M2 change · d75d9e73
      由 Paul Walmsley 提交于 
      Where necessary, add interconnect barriers to force posted writes to
complete before continuing.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d75d9e73
    • P
      OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpll · 69d4255b
      由 Paul Walmsley 提交于 
      Add more barriers in the SRAM CORE DPLL M2 divider change code.

- Add a DSB SY after the function's entry point to flush all cached
  and buffered writes and wait for the interconnect to claim that they
  have completed[1].  The idea here is to force all delayed write
  traffic going to the SDRAM to at least post to the L3 interconnect
  before continuing.  If these writes are allowed to occur after the
  SDRC is idled, the writes will not be acknowledged and the ARM will
  stall.

  Note that in this case, it does not matter if the writes actually
  complete to the SDRAM - it is only necessary for the writes to leave
  the ARM itself.  If the writes are posted by the interconnect when
  the SDRC goes into idle, the writes will be delayed until the SDRC
  returns from idle[2].  If the SDRC is in the middle of a write when
  it is requested to enter idle, the SDRC will not acknowledge the
  idle request until the writes complete to the SDRAM.[3]

  The old-style DMB in sdram_in_selfrefresh is now superfluous, so,
  remove it.

- Add an ISB before the function's exit point to prevent the ARM from
  speculatively executing into SDRAM before the SDRAM is enabled[4].

...

1. ARMv7 ARM (DDI 0406A) A3-47, A3-48.

2. Private communication with Richard Woodruff <r-woodruff2@ti.com>.

3. Private communication with Richard Woodruff <r-woodruff2@ti.com>.

4. ARMv7 ARM (DDI 0406A) A3-48.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      69d4255b
    • P
      OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory · d9295746
      由 Paul Walmsley 提交于 
      Mark the SRAM (aka OCM RAM) as Non-cacheable Normal memory[1].  This
is to prevent the ARM from evicting existing cache lines to SDRAM
while code is executing from the SRAM.  Necessary since one of the
primary uses for the SRAM is to hold the code and data for the CORE
DPLL M2 divider reprogramming code, which must execute while the SDRC
is idled.  If the ARM attempts to write cache lines back to the while
the SRAM code is running, the ARM will stall[2].

TI deals with this problem in the CDP kernel by marking the SRAM as
Strongly-ordered memory.

Tero Kristo <tero.kristo@nokia.com> caught a bug in an earlier version of
this patch - thanks Tero.

...

1. ARMv7 ARM (DDI 0406A) pp. A3-30, A3-31, B3-32.

2. Private communication with Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <tero.kristo@nokia.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
      d9295746