IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Initialize PCI/PCIe on the QNAP TS-119, TS-219 and TS-219P hardware
allowing the use of the discrete eSATA controller connected to the PCIe
bus in the TS-219P.
Signed-off-by: John Holland <john.holland@cellent-fs.de>
Tested-by: Thomas Reitmayr <treitmayr@devbase.at>
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Always creating the physical mapping should do no harm, so let's remove
the interface that was provided for its optional creation and make the
mapping static.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
We don't have to define resources to the minimal physical window size
as setup_cpu_win() will cope with smaller sizes already.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The Orion watchdog driver is also used on Kirkwood.
Convention is to use orion5x for stuff specific to 88F5xxx Orion chips
and simply "orion" for shared stuff across SoCs including Kirkwood.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The Kirkwood architecture uses the same watchdog device as the Orion
architecture. This patch adds orion5x_wdt as a platform device for
Kirkwood.
Signed-off-by: Thomas Reitmayr <treitmayr@devbase.at>
Tested-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
To save power:
1. Enabling clock gating of unused peripherals
2. PLL and PHY of the units are also disabled (when possible.
Signed-off-by: Rabeeh Khoury <rabeeh@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Common resource and platform device structures are moved to common.c
and only the partition table and chip delay remains a per board
parameter.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Just like commit 1419468ab5, let's save some TLB entries by making
ioremap() return pointers into the boot-time Kirkwood peripheral
iotable mapping whenever someone tries to ioremap any part of the Kirkwood
peripheral register space.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The patch adds support for Kirkwood cpu idle.
Two idle states are defined:
1. Wait-for-interrupt (replacing default kirkwood wfi)
2. Wait-for-interrupt and DDR self refresh
Signed-off-by: Rabeeh Khoury <rabeeh@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Since commit eb0519b5a1, mv643xx_eth is non functional on ARM because
the platform device declaration does not include any coherent DMA mask
and coherent memory allocations fail.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Remove explicit names from platform device resources since they will
automatically be named after the platform device they're associated
with.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
For the QNAP TS-119 and TS-219 the wrong MPPs were used for the SATA
activity/presence LEDs. The new settings make these LEDs work as
expected.
Signed-off-by: Thomas Reitmayr <treitmayr@devbase.at>
Tested-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Symbols like SOFT_RESET are way too generic to be exported at large.
To avoid this, let's move the mbus bridge register defines into a
separate file and include it where needed. This affects mach-kirkwood,
mach-loki, mach-mv78xx0 and mach-orion5x simultaneously as they all
share code in plat-orion which relies on those defines.
Some other defines have been moved to narrower scopes, or simply deleted
when they had no user.
This fixes compilation problem with mpt2sas on the above listed
platforms.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32)
Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64)
Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for the QNAP TS-119 and TS-219 Turbo NAS devices.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
With the exception of UART0, all MPP names are uppercase.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Hook up I2C on Marvell Kirkwood. Tested on a QNAP TS-219 which has
RTC connected through I2C.
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips. This patch adds support
for multiple switch chips on a network interface.
An example topology for a 16-port device with an embedded CPU is as
follows:
+-----+ +--------+ +--------+
| |eth0 10| switch |9 10| switch |
| CPU +----------+ +-------+ |
| | | chip 0 | | chip 1 |
+-----+ +---++---+ +---++---+
|| ||
|| ||
||1000baseT ||1000baseT
||ports 1-8 ||ports 9-16
This requires a couple of interdependent changes in the DSA layer:
- The dsa platform driver data needs to be extended: there is still
only one netdevice per DSA driver instance (eth0 in the example
above), but each of the switch chips in the tree needs its own
mii_bus device pointer, MII management bus address, and port name
array. (include/net/dsa.h) The existing in-tree dsa users need
some small changes to deal with this. (arch/arm)
- The DSA and Ethertype DSA tagging modules need to be extended to
use the DSA device ID field on receive and demultiplex the packet
accordingly, and fill in the DSA device ID field on transmit
according to which switch chip the packet is heading to.
(net/dsa/tag_{dsa,edsa}.c)
- The concept of "CPU port", which is the switch chip port that the
CPU is connected to (port 10 on switch chip 0 in the example), needs
to be extended with the concept of "upstream port", which is the
port on the switch chip that will bring us one hop closer to the CPU
(port 10 for both switch chips in the example above).
- The dsa platform data needs to specify which ports on which switch
chips are links to other switch chips, so that we can enable DSA
tagging mode on them. (For inter-switch links, we always use
non-EtherType DSA tagging, since it has lower overhead. The CPU
link uses dsa or edsa tagging depending on what the 'root' switch
chip supports.) This is done by specifying "dsa" for the given
port in the port array.
- The dsa platform data needs to be extended with information on via
which port to reach any given switch chip from any given switch chip.
This info is specified via the per-switch chip data struct ->rtable[]
array, which gives the nexthop ports for each of the other switches
in the tree.
For the example topology above, the dsa platform data would look
something like this:
static struct dsa_chip_data sw[2] = {
{
.mii_bus = &foo,
.sw_addr = 1,
.port_names[0] = "p1",
.port_names[1] = "p2",
.port_names[2] = "p3",
.port_names[3] = "p4",
.port_names[4] = "p5",
.port_names[5] = "p6",
.port_names[6] = "p7",
.port_names[7] = "p8",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
.rtable = (s8 []){ -1, 9, },
}, {
.mii_bus = &foo,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[10] = "dsa",
.rtable = (s8 []){ 10, -1, },
},
},
static struct dsa_platform_data pd = {
.netdev = &foo,
.nr_switches = 2,
.sw = sw,
};
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
OMAP wishes to pass state to the boot loader upon reboot in order to
instruct it whether to wait for USB-based reflashing or not. There is
already a facility to do this via the reboot() syscall, except we ignore
the string passed to machine_restart().
This patch fixes things to pass this string to arch_reset(). This means
that we keep the reboot mode limited to telling the kernel _how_ to
perform the reboot which should be independent of what we request the
boot loader to do.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Ideally, the default should be set to 0 and let the EHCI driver turn
it on as needed. This makes USB usable in the mean time.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The RTC and the two XOR engines are internal to the chip, and therefore
always available since they don't depend on a particular board layout.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
This allows for board support code to set up their MPP config if the
bootloader didn't do it all or did it wrong. This also allows to
register usable GPIOs.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The GPIO interrupts can be configured as either level triggered or edge
triggered, with a default of level triggered. When an edge triggered
interrupt is requested, the gpio_irq_set_type method is called which
currently switches the given IRQ descriptor between two struct irq_chip
instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
happens via __setup_irq() which also calls irq_chip_set_defaults() to
assign default methods to uninitialized ones. The problem is that
irq_chip_set_defaults() is called before the irq_chip reference is
switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
case) with uninitialized methods such as chip->startup() causing a kernel
oops.
Many solutions are possible, such as making irq_chip_set_defaults() global
and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
before irq_chip_set_defaults() in __setup_irq(). But those require
modifications to the generic IRQ code which might have adverse effect on
other architectures, and that would still be a fragile arrangement.
Manually copying the missing methods from within gpio_irq_set_type()
would be really ugly and it would break again the day new methods with
automatic defaults are added.
A better solution is to have a single irq_chip instance which can deal
with both edge and level triggered interrupts. It is also a good idea
to switch the IRQ handler instead, as the edge IRQ handler allows for
one edge IRQ event to be queued as the IRQ is actually masked only when
that second IRQ is received, at which point the hardware can queue an
additional IRQ event, making edge triggered interrupts a bit more
reliable.
Tested-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Otherwise the mv643xx_eth driver will assume 133 MHz which is incorrect.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On newer versions of the RD88F6281 board, the WAN port is connected to
its own ethernet port on the CPU, via a separate PHY, whereas on older
versions of the board, it is connected to one of the PHYs in the
ethernet switch. In the RD8F6281 setup code, detect which version of
the board we are running on, and instantiate the ethernet ports and
switch driver accordingly.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The 88f6192 and 88f6281 Kirkwood SoCs support two ethernet ports.
Add the platform glue that will allow board support files to
instantiate the second ethernet port.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
The Orion ehci driver serves the Orion, kirkwood and DD Soc families.
Since each of those integrate a different USB phy we should have the
ability to use few initialization sequences or to leave the boot loader
phy settings as is.
Signed-off-by: Ronen Shitrit <rshitrit@marvell.com>
