C6X: devicetree support
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 <msalter@redhat.com>
Signed-off-by: Aurelien Jacquiot <a-jacquiot@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2011-10-04 16:12:20 +00:00
|
|
|
Device State Configuration Registers
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
|
|
|
|
TI C6X SoCs contain a region of miscellaneous registers which provide various
|
|
|
|
|
function for SoC control or status. Details vary considerably among from SoC
|
|
|
|
|
to SoC with no two being alike.
|
|
|
|
|
|
2013-06-27 10:54:45 +00:00
|
|
|
In general, the Device State Configuration Registers (DSCR) will provide one or
|
C6X: devicetree support
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 <msalter@redhat.com>
Signed-off-by: Aurelien Jacquiot <a-jacquiot@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2011-10-04 16:12:20 +00:00
|
|
|
more configuration registers often protected by a lock register where one or
|
|
|
|
|
more key values must be written to a lock register in order to unlock the
|
|
|
|
|
configuration register for writes. These configuration register may be used to
|
|
|
|
|
enable (and disable in some cases) SoC pin drivers, select peripheral clock
|
|
|
|
|
sources (internal or pin), etc. In some cases, a configuration register is
|
|
|
|
|
write once or the individual bits are write once. In addition to device config,
|
2015-01-02 13:54:39 +00:00
|
|
|
the DSCR block may provide registers which are used to reset peripherals,
|
C6X: devicetree support
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 <msalter@redhat.com>
Signed-off-by: Aurelien Jacquiot <a-jacquiot@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2011-10-04 16:12:20 +00:00
|
|
|
provide device ID information, provide ethernet MAC addresses, as well as other
|
|
|
|
|
miscellaneous functions.
|
|
|
|
|
|
|
|
|
|
For device state control (enable/disable), each device control is assigned an
|
|
|
|
|
id which is used by individual device drivers to control the state as needed.
|
|
|
|
|
|
|
|
|
|
Required properties:
|
|
|
|
|
|
|
|
|
|
- compatible: must be "ti,c64x+dscr"
|
|
|
|
|
- reg: register area base and size
|
|
|
|
|
|
|
|
|
|
Optional properties:
|
|
|
|
|
|
|
|
|
|
NOTE: These are optional in that not all SoCs will have all properties. For
|
|
|
|
|
SoCs which do support a given property, leaving the property out of the
|
|
|
|
|
device tree will result in reduced functionality or possibly driver
|
|
|
|
|
failure.
|
|
|
|
|
|
|
|
|
|
- ti,dscr-devstat
|
|
|
|
|
offset of the devstat register
|
|
|
|
|
|
|
|
|
|
- ti,dscr-silicon-rev
|
|
|
|
|
offset, start bit, and bitsize of silicon revision field
|
|
|
|
|
|
|
|
|
|
- ti,dscr-rmii-resets
|
|
|
|
|
offset and bitmask of RMII reset field. May have multiple tuples if more
|
|
|
|
|
than one ethernet port is available.
|
|
|
|
|
|
|
|
|
|
- ti,dscr-locked-regs
|
|
|
|
|
possibly multiple tuples describing registers which are write protected by
|
|
|
|
|
a lock register. Each tuple consists of the register offset, lock register
|
|
|
|
|
offsset, and the key value used to unlock the register.
|
|
|
|
|
|
|
|
|
|
- ti,dscr-kick-regs
|
|
|
|
|
offset and key values of two "kick" registers used to write protect other
|
|
|
|
|
registers in DSCR. On SoCs using kick registers, the first key must be
|
|
|
|
|
written to the first kick register and the second key must be written to
|
|
|
|
|
the second register before other registers in the area are write-enabled.
|
|
|
|
|
|
|
|
|
|
- ti,dscr-mac-fuse-regs
|
|
|
|
|
MAC addresses are contained in two registers. Each element of a MAC address
|
|
|
|
|
is contained in a single byte. This property has two tuples. Each tuple has
|
|
|
|
|
a register offset and four cells representing bytes in the register from
|
|
|
|
|
most significant to least. The value of these four cells is the MAC byte
|
|
|
|
|
index (1-6) of the byte within the register. A value of 0 means the byte
|
|
|
|
|
is unused in the MAC address.
|
|
|
|
|
|
|
|
|
|
- ti,dscr-devstate-ctl-regs
|
|
|
|
|
This property describes the bitfields used to control the state of devices.
|
|
|
|
|
Each tuple describes a range of identical bitfields used to control one or
|
|
|
|
|
more devices (one bitfield per device). The layout of each tuple is:
|
|
|
|
|
|
|
|
|
|
start_id num_ids reg enable disable start_bit nbits
|
|
|
|
|
|
|
|
|
|
Where:
|
|
|
|
|
start_id is device id for the first device control in the range
|
|
|
|
|
num_ids is the number of device controls in the range
|
|
|
|
|
reg is the offset of the register holding the control bits
|
|
|
|
|
enable is the value to enable a device
|
|
|
|
|
disable is the value to disable a device (0xffffffff if cannot disable)
|
|
|
|
|
start_bit is the bit number of the first bit in the range
|
|
|
|
|
nbits is the number of bits per device control
|
|
|
|
|
|
|
|
|
|
- ti,dscr-devstate-stat-regs
|
|
|
|
|
This property describes the bitfields used to provide device state status
|
|
|
|
|
for device states controlled by the DSCR. Each tuple describes a range of
|
|
|
|
|
identical bitfields used to provide status for one or more devices (one
|
|
|
|
|
bitfield per device). The layout of each tuple is:
|
|
|
|
|
|
|
|
|
|
start_id num_ids reg enable disable start_bit nbits
|
|
|
|
|
|
|
|
|
|
Where:
|
|
|
|
|
start_id is device id for the first device status in the range
|
|
|
|
|
num_ids is the number of devices covered by the range
|
|
|
|
|
reg is the offset of the register holding the status bits
|
|
|
|
|
enable is the value indicating device is enabled
|
|
|
|
|
disable is the value indicating device is disabled
|
|
|
|
|
start_bit is the bit number of the first bit in the range
|
|
|
|
|
nbits is the number of bits per device status
|
|
|
|
|
|
|
|
|
|
- ti,dscr-privperm
|
|
|
|
|
Offset and default value for register used to set access privilege for
|
|
|
|
|
some SoC devices.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
device-state-config-regs@2a80000 {
|
|
|
|
|
compatible = "ti,c64x+dscr";
|
|
|
|
|
reg = <0x02a80000 0x41000>;
|
|
|
|
|
|
|
|
|
|
ti,dscr-devstat = <0>;
|
|
|
|
|
ti,dscr-silicon-rev = <8 28 0xf>;
|
|
|
|
|
ti,dscr-rmii-resets = <0x40020 0x00040000>;
|
|
|
|
|
|
|
|
|
|
ti,dscr-locked-regs = <0x40008 0x40004 0x0f0a0b00>;
|
|
|
|
|
ti,dscr-devstate-ctl-regs =
|
|
|
|
|
<0 12 0x40008 1 0 0 2
|
|
|
|
|
12 1 0x40008 3 0 30 2
|
|
|
|
|
13 2 0x4002c 1 0xffffffff 0 1>;
|
|
|
|
|
ti,dscr-devstate-stat-regs =
|
|
|
|
|
<0 10 0x40014 1 0 0 3
|
|
|
|
|
10 2 0x40018 1 0 0 3>;
|
|
|
|
|
|
|
|
|
|
ti,dscr-mac-fuse-regs = <0x700 1 2 3 4
|
|
|
|
|
0x704 5 6 0 0>;
|
|
|
|
|
|
|
|
|
|
ti,dscr-privperm = <0x41c 0xaaaaaaaa>;
|
|
|
|
|
|
|
|
|
|
ti,dscr-kick-regs = <0x38 0x83E70B13
|
|
|
|
|
0x3c 0x95A4F1E0>;
|
|
|
|
|
};
|
