- 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:
Olof Johansson <olof@lixom.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:Arnd Bergmann <arnd@arndb.de> 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 20 commits
-
-
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:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Atsushi Yamagata <yamagata@plathome.co.jp> Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-
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:
-
Thomas Petazzoni authored
The Kirkwood iConnect Device Tree is currently using totally meaningless names for the pinmux configuration: pmx_gpio_XY. This patch fixes that by using some more meaningful names such as pmx_button_power. 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:
-
