- 11 Jun, 2013 1 commit
-
-
git://git.infradead.org/users/jcooper/linuxOlof Johansson authored
From Jason Cooper: mvebu dt changes for v3.11 (round 4) - kirkwood - reshuffle nodes from kirkwood.dtsi to -6281.dtsi, etc - add i2c-gpio for km_kirkwood - add cpu node so pending cpufreq driver will init * tag 'dt-3.11-4' of git://git.infradead.org/users/jcooper/linux: ARM: Kirkwood add cpus definition needed by cpufreq driver to dtsi ARM: kirkwood: add i2c-gpio controller for km_kirkwood ARM: kirkwood: refactor dtsi to largest common nodes Signed-off-by:Olof Johansson <olof@lixom.net>
-
- 10 Jun, 2013 1 commit
-
-
Arnd Bergmann authored
A recent series has added CPU numbers to a lot of dts files, but unfortunately in a few cases the #address-cells and #size-cells values are missing, which causes build warnings. This adds the missing ones for sunxi and sama5 that I found through build testing. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 08 Jun, 2013 1 commit
-
-
git://github.com/linux-wmt/linux-vtwmOlof Johansson authored
From Tony Prisk, vt8500 devicetree updates for 3.11. * tag 'vt8500/dts-3.11' of git://github.com/linux-wmt/linux-vtwm: dts: vt8500: Correct reference clock on WM8850 SoCs dts: vt8500: Add ARM, AHB, APB and DDR clock nodes to SoC files dts: vt8500: Populate missing PLL nodes dts: clk: vt8500: Update SoC dtsi to use WM8850 PLL clocks dts: vt8500: Update serial nodes and disable by default in SoC files dts: vt8500: Add devicetree support for WM8750 SoC and APC8750 board dts: vt8500: Fix invalid/missing cpu nodes for soc files. Signed-off-by:
-
- 07 Jun, 2013 1 commit
-
-
git://linux-arm.org/linux-2.6-lpOlof Johansson authored
From Lorenzo Pieralisi, this is a series of patches that cleans up the CPU nodes in most of the SoC dtsi files to conform to the standard bindings. * 'dts-cpus-updates' of git://linux-arm.org/linux-2.6-lp: ARM: dts: sunxi: cpus/cpu nodes dts updates ARM: dts: spear: cpus/cpu nodes dts updates ARM: dts: sh7372: cpus/cpu nodes dts updates ARM: dts: r8a7740: cpus/cpu nodes dts updates ARM: dts: pxa2xx: cpus/cpu nodes dts updates ARM: dts: prima2: cpus/cpu node dts updates ARM: dts: picoxcell: cpus/cpu nodes dts updates ARM: dts: omap: cpus/cpu nodes dts updates ARM: dts: lpc32xx: cpus/cpu nodes dts updates ARM: dts: imx: cpus/cpu nodes dts updates ARM: dts: exynos5440: cpus/cpu nodes dts updates ARM: dts: at91: cpus/cpu node dts updates ARM: dts: armada-370-xp: cpus/cpu node dts updates ARM: dts: am33xx: cpus/cpu nodes dts updates Signed-off-by:
-
- 03 Jun, 2013 2 commits
-
-
Tony Prisk authored
WM8850 SoCs use a 24Mhz reference clock for the PLLs but the SoC file currently parents all PLLs to the 25Mhz reference clock. This patch corrects the PLL parent clock references. Signed-off-by:Tony Prisk <linux@prisktech.co.nz>
-
Adam Baker authored
The Kirkwood CPU Freq driver needs a CPU definition in order for the probe routine to activate it. Add a suitable definition to kirkwood.dtsi This definition is only correct for single core SoCs. There is a dual core SoC in the kirkwood family (88F632X) but the rest of the Kirkwood drivers in the kernel don't currently support it. If they ever do the cpus definition would need to be duplicated in each of the SoC specific include files. Signed-off-by:
Adam Baker <linux@baker-net.org.uk> Tested-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-
- 01 Jun, 2013 3 commits
-
-
git://github.com/at91linux/linux-at91Olof Johansson authored
From Nicolas Ferre: Big DT-centric update for AT91: - Calao boards update, removal of one board C file and associated defconfig, Kconfig Makefile lines - several Acme boards updates - addition of watchdog, uart and pinctrl descriptions for several products - modification of RTC compatible string for 9x5 family * tag 'at91-dt' of git://github.com/at91linux/linux-at91: (21 commits) ARM: at91/dt: add pinctrl definition for at91 tc blocks ARM: at91/dts: add the watchdog nodes for at91 boards ARM: at91/dtsi: add the watchdog nodes for at91 SoC ARM: at91: drop non DT: Calao USB-A96x ARM: at91: dt: add Calao USB-A9G20 low power version ARM: at91: dt: usb-a9263: add dataflash support ARM: at91: dt: usb-a9263: update shutdown controller ARM: at91: dt: usb-a9260: update shutdown controller ARM: at91: dt: sam9260: add i2c gpio pinctrl ARM: at91: switch Fox G20 board .dts to pre-processor defines ARM: at91: add Acme Systems Fox G20 board ARM: at91/at91-ariag25.dts: UART0/1 nodes are disabled ARM: at91/at91sam9x5.dtsi: add UART0/1 nodes ARM: at91/at91-ariag25.dts: add RTC node ARM: at91: at91sam9x5 RTC is not compatible with at91rm9200 one ARM: at91: udpate defconfigs ARM: at91: dt: switch to standard IRQ flag defines ARM: at91: dt: switch to pinctrl to pre-processor ARM: at91: dt: add pinctrl pre-processor define ARM: at91: dt: switch to standard GPIO flag defines. ... Signed-off-by:
-
Arnd Bergmann authored
The clocksource API has changed slightly, which causes a harmless warning: /git/arm-soc/drivers/clocksource/nomadik-mtu.c:259:28: warning: 'nmdk_timer_match' defined but not used [-Wunused-variable] static struct of_device_id nmdk_timer_match[] __initconst = { ^ Fortunately, the same API change also lets us simplify the code while removing the warning. Signed-off-by: -
git://git.infradead.org/users/jcooper/linuxOlof Johansson authored
From jason Cooper, mvebu dt changes for v3.11. Signed-off-by:
-
- 31 May, 2013 15 commits
-
-
Boris BREZILLON authored
This patch adds pinctrl configurations for at91 Timer Counter blocks. These pin definitions can be referenced by "atmel,tcb-pwm" devices to setup pins as PWM output for instance. Signed-off-by:
Boris BREZILLON <b.brezillon@overkiz.com> [nicolas.ferre@atmel.com: switch to pinctrl pre-processor macros] Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com>
-
Wenyou Yang authored
boards include: at91sam9263ek, at91sam9g20ek, at91sam9m10g45ek, at91sam9n12ek, at91sam9x5ek Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> Tested-by:
Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
-
Wenyou Yang authored
at91sam9x5, at91sam9n12 Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
as now we have full DT support of those board Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
the low power version have a mmc-spi eanble mmc-spi and RV3029C2 RTC in at91_dt_defconfig Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
enable rtt and wakeup button (5 msec low) Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
enable rtt and wakeup button (5 msec low) Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
Signed-off-by:
-
Nicolas Ferre authored
Signed-off-by: -
Douglas Gilbert authored
Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> [nicolas.ferre@atmel.com: re-arranging nodes, removing nodes and some comments] Signed-off-by:
-
Nicolas Ferre authored
UART0 is moved to generic at91sam9x5.dtsi file. Both uarts are "disabled" as the corresponding pins on Aria documentation are shown as GPIOs. Signed-off-by: -
Nicolas Ferre authored
Reported-by:
-
Nicolas Ferre authored
Reported-by:
-
Nicolas Ferre authored
Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible with the previous one. Modify DT compatibility string, even if the driver is not yet modified to take it into account. Signed-off-by:
-
- 28 May, 2013 1 commit
-
-
Olof Johansson authored
Merge tag 'nomadik-dt-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into next/dt From Linus Walleij: Device tree patches for the Nomadik machine: - Move clock registration to the device tree - Support probing the MTU timer from the device tree - Register user LED and user key in the device tree - Update defconfig to account for user LED and user key - Move pin control mappings to the device tree * tag 'nomadik-dt-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik: ARM: nomadik: move the pin configuration to DT ARM: nomadik: add led and key for S8815 ARM: nomadik: register clocksource from device tree ARM: nomadik: convert all clocks except timer to dt clocksource: nomadik-mtu: support of probe Signed-off-by:
-
- 27 May, 2013 15 commits
-
-
Valentin Longchamp authored
This controller is used to access the reset management FPGA of the km_kirkwood boards. Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by:
-
Valentin Longchamp authored
Some kirkwood variants (for instance present in the prestera SoCs) do not have all the peripherals whose nodes are declared in kirkwood.dtsi. These missing peripherals are SATA, SDIO, and RTC. As discussed in [1], to avoid that these missing peripherals get initialized which could result in system hangs when accessing undocumented/not present HW registers, their corresponding OF nodes should not get declared at all for some kirkwood variants. The corresponding OF nodes of these peripherals thus are moved from kirkwood.dtsi to the kirkwood-628x.dtsi files so that they still are initialized for these variants where they are present. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/167154.htmlSigned-off-by:
-
Thomas Petazzoni authored
The Kirkwood-based PlatHome OpenBlocks A6 board has an Init button connected to MPP pin 38. This commit adds support for this button. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Atsushi Yamagata <yamagata@plathome.co.jp> Signed-off-by:
-
Thomas Petazzoni authored
Instead of having one separate pinmux configuration for each LED, for each GPIO of the GPIO header, for each DIP switch, this patch groups them together in configurations that make sense together: LEDs on one side, GPIOs of the GPIO header on another side, and DIP switches on yet another side. Signed-off-by:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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. Note that some of the LEDs pinmux configurations are kept in the pinctrl node, because they are not used by the gpio-leds driver. 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:
-
Thomas Petazzoni authored
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:
-
