09 Jan, 2012
2 commits
-
Some SoCs have a timer block enable controlled through the DSCR registers.
There is a problem in the timer64 driver initialization where the code
accesses a timer register to get the divisor used to calculate timer clock
rate. If the timer block has not been enabled when this register read takes
place, an exception is generated. This patch makes sure that the timer block
is enabled before accessing the registers.Signed-off-by: Mark Salter
-
Signed-off-by: Mark Salter
07 Oct, 2011
8 commits
-
All SoCs provide an area of device configuration registers called the DSCR. The
location of specific registers as well as their use varies considerably from
implementation to implementation. Rather than having to rely on additional
SoC-specific DSCR code for each new supported SoC, this code generalize things
as much as possible using device tree properties. Initialization must take
place early on (setup_arch time) in case the event timer device needs to be
enable via the DSCR.Signed-off-by: Mark Salter
Signed-off-by: Aurelien Jacquiot
Acked-by: Arnd Bergmann -
Several SoC parts provide a simple bridge to support external memory mapped
devices. This code probes the device tree for an EMIF node and sets up the
bridge registers if such a node is found. Beyond initial set up, there is no
further need to access the bridge control registers. External devices on the
bus are accessed through their MMIO registers using suitable drivers. The
bridge hardware does provide for timeout and other error interrupts, but these
are not yet supported.Signed-off-by: Mark Salter
Signed-off-by: Aurelien Jacquiot
Acked-by: Arnd Bergmann -
Original port to early 2.6 kernel using TI COFF toolchain.
Brought up to date by Mark SalterSigned-off-by: Aurelien Jacquiot
Signed-off-by: Mark Salter
Acked-by: Arnd Bergmann -
The C6X SoCs contain several PLL controllers each with up to 16 clock outputs
feeding into the cores or peripheral clock domains. The hardware is very similar
to arm/mach-davinci clocks. This is still a work in progress which needs to be
updated once device tree clock binding changes shake out.Signed-off-by: Mark Salter
Signed-off-by: Aurelien Jacquiot
Acked-by: Arnd Bergmann -
Original port to early 2.6 kernel using TI COFF toolchain.
Brought up to date by Mark SalterSigned-off-by: Aurelien Jacquiot
Signed-off-by: Mark Salter
Reviewed-by: Thomas Gleixner
Acked-by: Arnd Bergmann -
Original port to early 2.6 kernel using TI COFF toolchain.
Brought up to date by Mark SalterSigned-off-by: Aurelien Jacquiot
Signed-off-by: Mark Salter
Reviewed-by: Thomas Gleixner
Acked-by: Arnd Bergmann -
This is the basic devicetree support for C6X. Currently, four boards are
supported. Each one uses a different SoC part. Two of the four supported
SoCs are multicore. One with 3 cores and the other with 6 cores. There is
no coherency between the core-level caches, so SMP is not an option. It is
possible to run separate kernel instances on the various cores. There is
currently no C6X bootloader support for device trees so we build in the DTB
for now.There are some interesting twists to the hardware which are of note for device
tree support. Each core has its own interrupt controller which is controlled
by special purpose core registers. This core controller provides 12 general
purpose prioritized interrupt sources. Each core is contained within a
hardware "module" which provides L1 and L2 caches, power control, and another
interrupt controller which cascades into the core interrupt controller. These
core module functions are controlled by memory mapped registers. The addresses
for these registers are the same for each core. That is, when coreN accesses
a module-level MMIO register at a given address, it accesses the register for
coreN even though other cores would use the same address to access the register
in the module containing those cores. Other hardware modules (timers, enet, etc)
which are memory mapped can be accessed by all cores.The timers need some further explanation for multicore SoCs. Even though all
timer control registers are visible to all cores, interrupt routing or other
considerations may make a given timer more suitable for use by a core than
some other timer. Because of this and the desire to have the same image run
on more than one core, the timer nodes have a "ti,core-mask" property which
is used by the driver to scan for a suitable timer to use.Signed-off-by: Mark Salter
Signed-off-by: Aurelien Jacquiot
Acked-by: Arnd Bergmann -
Original port to early 2.6 kernel using TI COFF toolchain.
Brought up to date by Mark SalterSigned-off-by: Aurelien Jacquiot
Signed-off-by: Mark Salter
Acked-by: Arnd Bergmann
