Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 26 8月, 2009 24 次提交
  3. 26 7月, 2009 5 次提交
  5. 06 6月, 2009 1 次提交
  7. 31 5月, 2009 1 次提交
  9. 30 5月, 2009 1 次提交
  11. 29 5月, 2009 8 次提交
    • D
      davinci: add SRAM allocator · 20e9969b
      由 David Brownell 提交于 
      Provide a generic SRAM allocator using genalloc, and vaguely
modeled after what AVR32 uses.  This builds on top of the
static CPU mapping set up in the previous patch, and returns
DMA mappings as requested (if possible).

Compared to its OMAP cousin, there's no current support for
(currently non-existent) DaVinci power management code running
in SRAM; and this has ways to deallocate, instead of being
allocate-only.

The initial user of this should probably be the audio code,
because EDMA from DDR is subject to various dropouts on at
least DM355 and DM6446 chips.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      20e9969b
    • D
      davinci: soc-specific SRAM setup · 0d04eb47
      由 David Brownell 提交于 
      Package on-chip SRAM.  It's always accessible from the ARM, so
set up a standardized virtual address mapping into a 128 KiB
area that's reserved for platform use.

In some cases (dm6467) the physical addresses used for EDMA are
not the same as the ones used by the ARM ... so record that info
separately in the SOC data, for chips (unlike the OMAP-L137)
where SRAM may be used with EDMA.

Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM,
may be unused/available on some system.  They are ignored here.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      0d04eb47
    • D
      davinci: remove remnants of IRAM allocator · b79dbdef
      由 David Brownell 提交于 
      Remove remnants of dm6446-specific SRAM allocator, as preparation for
a more generic replacement.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b79dbdef
    • K
      davinci: cleanup: move dm355 UART2 define to dm355.c · 96ed299f
      由 Kevin Hilman 提交于 
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      96ed299f
    • M
      davinci: Move PINMUX defines to SoC files · 5570078c
      由 Mark A. Greer 提交于 
      Different SoC have different numbers of pinmux registers and other
resources that overlap with each other.  To clean up the code and
eliminate defines that overlap with each other, move the PINMUX
defines to the SoC specific files.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      5570078c
    • M
      davinci: Add compare register support to timer code · 3abd5acf
      由 Mark A. Greer 提交于 
      The Timer64p timer has 8 compare registers that can
be used to generate interrupts when the timer value
matches the compare reg's value.  They do not disturb
the timer itself.  This can be useful when there is
only one timer available for both clock events and
clocksource.

When enabled, the clocksource remains a continuous
32-bit counter but the clock event will no longer
support periodic interrupts.  Instead only oneshot
timers will be supported and implemented by setting
the compare register to the current timer value plus
the period that the clock event subsystem is requesting.

Compare registers support is enabled automatically
when the following conditions are met:
1) The same timer is being used for clock events
   and clocksource.
2) The timer is the bottom half (32 bits) of the
   64-bit timer (hardware limitation).
3) The the compare register offset and irq are
   not zero.

Since the timer is always running, there is a hardware
race in timer32_config() between reading the current
timer value, and adding the period to the current
timer value and writing the compare register.
Testing on a da830 evm board with the timer clocked
at 24 MHz and the processor clocked at 300 MHz,
showed the number of counter ticks to do this ranged
from 20-53 (~1-2.2 usecs) but usually around 41 ticks.
This includes some artifacts from collecting the
information.  So, the minimum period should be
at least 5 usecs to be safe.

There is also an non-critical lower limit that
the period should be since there is no point in
setting an event that is much shorter than the
time it takes to set the event, and get & handle
the timer interrupt for that event.  There can
also be all sorts of delays from activities
occuring elsewhere in the system (including
hardware activitis like cache & TLB management).
These are virtually impossible to quantify so a
minimum period of 50 usecs was chosen.  That will
certianly be enough to avoid the actual hardware
race but hopefully not large enough to cause
unreasonably course-grained timers.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      3abd5acf
    • M
      davinci: Integrate cp_intc support into low-level irq code · 0b0c4c2a
      由 Mark A. Greer 提交于 
      Integrate the Common Platform Interrupt Controller (cp_intc)
support into the low-level irq handling for davinci and similar
platforms.  Do it such that support for cp_intc and the original
aintc can coexist in the same kernel binary.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      0b0c4c2a
    • M
      davinci: Factor out emac mac address handling · b14dc0f9
      由 Mark A. Greer 提交于 
      Factor out the code to extract that mac address from
i2c eeprom.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      b14dc0f9