Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of the ocp node, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to
correspond to each MBus window.

In addition, we encode the PCIe memory and I/O apertures in the MBus
node, according to the MBus DT binding specification. The choice made
is 0xe0000000-0xf0000000 for memory space, and 0xf200000-0xf2100000 for
I/O space. These apertures can be changed in each per-board DT file.
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Now that the PCIe mvebu driver is usable on Kirkwood, use it instead
of the legacy PCIe code, since it allows to describe the PCIe
interfaces in the Device Tree.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

When the pinmux mechanism was added in Kirkwood, the device driver
core was not yet providing the possibility of attaching pinmux
configurations to all devices, drivers had to do it explicitly, and
not all drivers were doing this.

Now that the driver core does that in a generic way, it makes sense to
attach the pinmux configuration to their corresponding devices.

This allows the pinctrl subsystem to show in debugfs to which device
is related which pins, for example:

pin 41 (PIN41): gpio-leds.1 mvebu-gpio:41 function gpio group mpp41
pin 42 (PIN42): gpio-leds.1 mvebu-gpio:42 function gpio group mpp42
pin 43 (PIN43): gpio-leds.1 mvebu-gpio:43 function gpio group mpp43
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

In order to prepare the switch to the standard MMC device tree parser
for mvsdio, adapt all current uses of mvsdio in the dts files to the
standard format.
Signed-off-by: NSimon Baatz <gmbnomis@gmail.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

When DT support for kirkwood was first introduced, there was no clock
infrastructure.  As a result, we had to manually pass the
clock-frequency to the driver from the device node.

Unfortunately, on kirkwood, with minimal config or all module configs,
clock-frequency breaks booting because of_serial doesn't consume the
gate_clk when clock-frequency is defined.

The end result on kirkwood is that runit gets gated, and then the boot
fails when the kernel tries to write to the serial port.

Fix the issue by removing the clock-frequency parameter from all
kirkwood dts files.

Booted on dreamplug without earlyprintk and successfully logged in via
ttyS0.
Reported-by: NSimon Baatz <gmbnomis@gmail.com>
Tested-by: NSimon Baatz <gmbnomis@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Now that the mvsdio driver has a Device Tree binding, and the SDIO
controller is declared in kirkwood.dtsi, migrate the mplcec4 board to
use the Device Tree to probe the SDIO controller and to mux the pins
of the SDIO interface correctly.

This patch has not been tested, it remains to be tested by a person
having access to the hardware.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Stefan Peter <s.peter@mpl.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Signed-off-by: NStefan Peter <s.peter@mpl.ch>
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Signed-off-by: NStefan Peter <s.peter@mpl.ch>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>