- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJRqRD8AAoJEAf03oE53VmQDXsIAI9uZ9Lrf3Hi5srFxMeDnJxD
LysPAz0BW+8XSC5CHCWhu8JxLtUnZy4y4yice/y2Uol0rzqb8gR40DRym/mHJF6t
zGRitG553zYe53rVGjOBX/e2sY+vhhm2slOdpxH5aB8ZES3WJxKYddqdvHhcwW3J
gzBP1S10mwspEuA7vQ+1r9k4WoGis7WVK1HLghga1yb4C/B5yFNhujZz3wweIIaw
eep55SDPiJhtVzlLOZOsVh3TZuSStyElfJTPk+UkFnz2QU1D7mJri55rPT121iGN
Vfc4NDAOyirOGTbSzY2cKSB53To8fipHRL0NzICCifkMuVzA2RWl13jOL/jo9QU=
=6Cw/
-----END PGP SIGNATURE-----
Merge tag 'at91-dt' of git://github.com/at91linux/linux-at91 into next/dt
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: Olof Johansson <olof@lixom.net>
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: Olof Johansson <olof@lixom.net>
- mvebu
- enable two usb interfaces on Armada XP-GP
- kirkwood
- move pinmux configs to their individual devices
- group the pinmux configs on OpenBlocks A6
- add the Init button for the OpenBlocks A6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRpPZAAAoJEAi3KVZQDZAe/6AIAIvtbKlec9up7/QoIzM7varY
Qfb7OU6EQYnNmTiY+n/y2REz03mUC/cnrvRZ0YD31i5WwHZWGQiz1R692Tt1e07A
Cugl75yLuOFnsSKqkvRy0Km2QF35Irk22stBRP85csGu/LjjSqr0gXDsJ2++oQfZ
ssco7I5MsTEFJDpeVAB5jFaFm+hs+uM8/WsUf7l7qjyImqkz1WZPZfkgevWm3UjH
Mz2Ur2Sbapq5gU+/h8GdzWJdCuSM0wmZ3TKGOk2BCbMFBFSr72tPUgVDwYge7Ae4
5lPoeHg00o8TM6kpf5OBGW8kq6oMij33e7YjVpAp/YdsAmyua1gFCFikW3APuJU=
=SWgl
-----END PGP SIGNATURE-----
Merge tag 'dt-3.11-3' of git://git.infradead.org/users/jcooper/linux into next/dt
From jason Cooper, mvebu dt changes for v3.11.
Signed-off-by: Olof Johansson <olof@lixom.net>
* tag 'dt-3.11-3' of git://git.infradead.org/users/jcooper/linux: (27 commits)
arm: kirkwood: openblocks-a6: add support for Init button
arm: kirkwood: openblocks-a6: group pinmux configurations
arm: kirkwood: ts219: move pinmux configs to the right devices
arm: kirkwood: topkick: move pinmux configs to the right devices
arm: kirkwood: openblocks_a6: move pinmux configs to the right devices
arm: kirkwood: nsa310: move pinmux configs to the right devices
arm: kirkwood: readynas: move pinmux configs to the right devices
arm: kirkwood: mplcec4: move pinmux configs to the right devices
arm: kirkwood: buffalo linkstation: move pinmux configs to the right devices
arm: kirkwood: keymile: move pinmux configs to the right devices
arm: kirkwood: ns2: move pinmux configs to the right devices
arm: kirkwood: iomega ix2-200: move pinmux configs to the right devices
arm: kirkwood: iconnect: move pinmux configs to the right devices
arm: kirkwood: iconnect: give meaningful names to pinmux configs
arm: kirkwood: ib62x0: move pinmux configs to the right devices
arm: kirkwood: guruplug: move pinmux configs to the right devices
arm: kirkwood: goflexnet: move pinmux configs to the right devices
arm: kirkwood: dreamplug: move pinmux configs to the right devices
arm: kirkwood: dockstar: move pinmux configs to the right devices
arm: kirkwood: dlink dns: move pinmux configs to the right devices
...
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>
at91sam9x5, at91sam9n12
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Tested-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
as now we have full DT support of those board
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
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 <plagnioj@jcrosoft.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
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 <nicolas.ferre@atmel.com>
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 <nicolas.ferre@atmel.com>
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: Nicolas Ferre <nicolas.ferre@atmel.com>
- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJRonB1AAoJEEEQszewGV1zKxIQAJApxkXQYacX2k/tBO8lseJF
D2FqAf75W9PKjYKOEQJ1LfqUL3nd1PDliGDxET3uk4sGaCb69GCa6aifPSW0S+B8
jV+URjgzFS5E0tEYApWwLbCa9grbjcyzAxCGAMEBakL6TUqrZu0XilfYEPZWiUSO
Xg4i196MoH/m8S97YmpBMLGtvQk2sQPzpawDMskjUIMkBWoSYVFOkQRZaA1gEwox
RjPPVuCYVjt0fpERYoFBF2yow0k+yaLqg/GXs6wT1oNl3kPbOx7TfAlztKcfRWWD
n0ojecLj5ov/aDgW26QxfUlN5ZuEOhaLrseq3TiWetp6+6dIvuXjXKhSY/1eWRa6
TdaDryYGxgkOpNoJGNxT1JMCYNgLklt+gcFSNEK76IeVMHph/j4Zvh8Plzi8Nx6P
AZ2n4mwkO+JQ0FgiOQKkBUfgwye7oVJtFsD4JDiIyo8paRbhBhlAb2QfmiArAA77
mBF6cz/Pe3q96n/cd9ryPwxoz2tQ8TcPaiUOCulU6qDG6DZdsAjzei9Hwnikq6D0
Tvv+u9lilWu+Atn+VArBgK9XFN+IBbpF7HZ9uuAzaAKmg/xZIdhgRunZcBC+laqx
Ft3cfhyVH9XVdRj/F6oYvWMSSFkzMd7cAtOVH2SaZcm3BIE/Uw99C6+/M+PVh9wR
tM43Wo98Exd66I/M9IfG
=wHd0
-----END PGP SIGNATURE-----
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: Olof Johansson <olof@lixom.net>
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>
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 <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>
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 <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Tested-By: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Tested-By: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: 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>
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 <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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.
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 <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
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 <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
do_smart_update_queue() is called when an operation (semop,
semctl(SETVAL), semctl(SETALL), ...) modified the array. It must check
which of the sleeping tasks can proceed.
do_smart_update_queue() missed a few wakeups:
- if a sleeping complex op was completed, then all per-semaphore queues
must be scanned - not only those that were modified by *sops
- if a sleeping simple op proceeded, then the global queue must be
scanned again
And:
- the test for "|sops == NULL) before scanning the global queue is not
required: If the global queue is empty, then it doesn't need to be
scanned - regardless of the reason for calling do_smart_update_queue()
The patch is not optimized, i.e. even completing a wait-for-zero
operation causes a rescan. This is done to keep the patch as simple as
possible.
Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This moves the pin configuration for the Nomadik over to the
device tree using Gabriel's bindings. Remove the auxdata
nailing down the name of the pin controller as this is no
longer necessary.
Cc: Gabriel Fernandez <gabriel.fernandez@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds device tree hunks for the LED and userbutton on the
USB S8815 board, and set up a heartbeat trigger on the LED and
an escape key on the user button. Alter the defconfig to enable
these standard DT-enabled GPIO drivers.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
- Stable fix to prevent an rpc_task wakeup race
- Fix a NFSv4.1 session drain deadlock
- Fix a NFSv4/v4.1 mount regression when not running rpc.gssd
- Ensure auth_gss pipe detection works in namespaces
- Fix SETCLIENTID fallback if rpcsec_gss is not available
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJRomGNAAoJEGcL54qWCgDyzUIQALj4hsOtdcmCCAWu0m+Pr+Gz
/6rpO2xJ5cLWyTYS2J9wmPkU+mb/g/OB/OhANyQQsDbfoW3e27TGaXRB8hUs29vk
LHTkFcrBTi4ohlw2Gyb6LWDF6cyHkC7cpH7tfIjLDff77V/qK1uqo41MtYpqUvy3
41tMoFOhvpwsy7HuKqVyYtNlwxnXrdJ5XvK0ycaQYQ9t8om9Hxu/scCgLfl/qwRr
eVhIesC2/Y1eC46UK7/TWCC7aTLkvi85UQY+fywMkajt/gPzjjh6nuhc45aOT9d7
pc0sXgIs8fLEjC+CRa0ojrziJZCHZY93U1kzA+CotRqPq76nPeFeG/1VhViKKb4C
1AU9IA4ntViUqNDQiGrCxE6ZeMewTOKksrCErwSS16Hv9Gqh4SHq84R/bF6MFgBc
dqQsexUbf/vaWHmuosARgbyc/QcBXDwWwbkq0hXSWbHA8vpc8/Lw1wkp49eyKz0V
0zwJ9xInakXr5/DIC72IKEF0Dg26L+GTXWLmDZVcdpVBp5A403trxUKckcsNa/Xf
FXaGMhyv2ZfV4AohW1Z8klkLiMHt4dr+YB7SQAgR/gb81p3odgKgMz51PfmHxFqs
4nxwRQqWplBTGiLrOFSgaRC50jLqEloUweWC2qf56KYEb9N6M6XDIXhllLIMyWLD
94cvihpKj+/ecKH5kQWF
=B8go
-----END PGP SIGNATURE-----
Merge tag 'nfs-for-3.10-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs
Pull NFS client bugfixes from Trond Myklebust:
- Stable fix to prevent an rpc_task wakeup race
- Fix a NFSv4.1 session drain deadlock
- Fix a NFSv4/v4.1 mount regression when not running rpc.gssd
- Ensure auth_gss pipe detection works in namespaces
- Fix SETCLIENTID fallback if rpcsec_gss is not available
* tag 'nfs-for-3.10-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
NFS: Fix SETCLIENTID fallback if GSS is not available
SUNRPC: Prevent an rpc_task wakeup race
NFSv4.1 Fix a pNFS session draining deadlock
SUNRPC: Convert auth_gss pipe detection to work in namespaces
SUNRPC: Faster detection if gssd is actually running
SUNRPC: Fix a bug in gss_create_upcall
Pull parisc fixes from Helge Deller:
"This time we made the kernel- and interruption stack allocation
reentrant which fixed some strange kernel crashes (specifically
protection ID traps).
Furthemore this patchset fixes the interrupt stack in UP and SMP
configurations by using native locking instructions. And finally
usage of floating point calculations on parisc were disabled in the
MPILIB."
* 'parisc-for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: fix irq stack on UP and SMP
parisc/superio: Use module_pci_driver to register driver
parisc: make interrupt and interruption stack allocation reentrant
parisc: show number of FPE and unaligned access handler calls in /proc/interrupts
parisc: add additional parisc git tree to MAINTAINERS file
parisc: use PAGE_SHIFT instead of hardcoded value 12 in pacache.S
parisc: add rp5470 entry to machine database
MPILIB: disable usage of floating point registers on parisc
- Fix for corruption with FSX on 512 byte blocksize filesystems
- Fix rounding error in xfs_free_file_space
- Fix use-after-free with extent free intents
- Add several missing KM_NOFS flags to fix lockdep reports
- Several fixes for CRC related code
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJRn93mAAoJENaLyazVq6ZOPw8P/1ab7Gr4K7ccpuRvC+JiBPx9
/Eb1l2A68r8rWJq3bEvLM/XgN7F0IESastS+iA8lrNuLWJAHCb+Y37mdbyWymhWO
J6LFg/Mic+n5uGmg6nXrqLJ8epTd3L+V+cCEHLpa/20zEwa5yd8sSTV0P1pfcMRi
S36Uof7boe+s4H/s2z4YX8Y+dkaVn1tN7j4PDs5Zd/wiUq0EKA5le4AkbqIJlCDn
E9mJL1S2t3QwfgQWL+pe8f5jzReGTAxJUQWX2ErajX4vYI7PnR1WTYf7YJB291f0
XPfkjqvaK0WCdipSkgb58t/Rj2IxoHItdryvBHa/rnL4e95aBQMpNyY8btNX28ou
NgcIQnqQB+xlJeHpSyb1xNusamGzWw0CEYsXPcDQbXj1uJjd7/GfqTwtVbB4zOlW
Hua7/6N22vaY1dfQcQFwgi1XcKF9jSVKBVOvy7yHEmdNuT7mFejaG1gVO7NpTIgd
s7R91pQVlYpLTmZHK6ZqZap5OC6kS/YJr9HxVxS3FQhaJmFwGqvf6UUjSWOK1MnJ
obTbbygo2Orvh10lgzDNsd+xRJZ9aFn+UfywSeQGTfm91HvTnEQje3xqctv3zmBy
adrWSXXg/eN07nciNk0zTgHnQZo1v/ZeAFlz0AcSslMMQ7Pq4+Pv4LPtdxMIdrxU
1IZ32GunGTUXqm6GRW6v
=hQCM
-----END PGP SIGNATURE-----
Merge tag 'for-linus-v3.10-rc3' of git://oss.sgi.com/xfs/xfs
Pull xfs fixes from Ben Myers:
"Here are fixes for corruption on 512 byte filesystems, a rounding
error, a use-after-free, some flags to fix lockdep reports, and
several fixes related to CRCs. We have a somewhat larger post -rc1
queue than usual due to fixes related to the CRC feature we merged for
3.10:
- Fix for corruption with FSX on 512 byte blocksize filesystems
- Fix rounding error in xfs_free_file_space
- Fix use-after-free with extent free intents
- Add several missing KM_NOFS flags to fix lockdep reports
- Several fixes for CRC related code"
* tag 'for-linus-v3.10-rc3' of git://oss.sgi.com/xfs/xfs:
xfs: remote attribute lookups require the value length
xfs: xfs_attr_shortform_allfit() does not handle attr3 format.
xfs: xfs_da3_node_read_verify() doesn't handle XFS_ATTR3_LEAF_MAGIC
xfs: fix missing KM_NOFS tags to keep lockdep happy
xfs: Don't reference the EFI after it is freed
xfs: fix rounding in xfs_free_file_space
xfs: fix sub-page blocksize data integrity writes
- Additional CPU ID for the intel_pstate driver from Dirk Brandewie.
- More cpufreq fixes related to ARM big.LITTLE support and locking from
Viresh Kumar.
- VIA C7 cpufreq build fix from Rafał Bilski.
- ACPI power management fix making it possible to use device power
states regardless of the CONFIG_PM setting from Rafael J. Wysocki.
- New ACPI video blacklist item from Bastian Triller.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJRoRZjAAoJEKhOf7ml8uNsv9wQAKAMs9J8k6XqgNPisFKetw+K
hzCOsKFOpI0BQKFikgtWjhGre1SyNIRUvLXO7BHFHXYQW6cLvn1jAyJhvl+i4nvT
eOa+vdGd6grWncbhIxeidoyk9hTZ6bdMWlTBvKUz5KpHzvp4YGC2jlvwFwqsJkpg
nQ8Hcbrbhm4vz5h7EmrlYcELBNTi5LQtmnqlxtbn02GX75BFTpkCm5aLZWZNEUrE
Hix8BhN41+hSy+K34ztHFlP5g/s/lIa9dOX1tewqSigkDB/qYYIt2lpdD2icOIOW
qHAtvpZq8/fZOcoZ9KdFqKUjjbuKVavldb+YzGeTLQufOAwb4hgMRvAccdNFMHIW
9tVkp2TcK6K7pAYlXtgEf25ka7ulLWDBd4C662gZfpi+oPKx2BI/6m7J4VoTULeb
30hDMyZXrXWWvStwO05Pyno3W5lG+cn9jytc3hKkaFerb53NHcZHfb0Rih5NhDZD
Ep09IuPE8fOT9KndY2kw/WwoZyJurYCbrgE+G1QyA+hsNPkNhPlGTxdL8vCqxM4K
ZOaQQejpd1bXBSk8Koz8LRyQ38KJByvM64B0EDSP6BQUT+rlbkcvog1bJV+UdpbJ
4TlhrAFlobhRFQBqlIbRqMXFPH31YSm7wVK1eK/gEqNZI935Kd17YSFf8yyi2yli
vBlmPkiPEIJHysps+tvd
=Srt8
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
- Additional CPU ID for the intel_pstate driver from Dirk Brandewie.
- More cpufreq fixes related to ARM big.LITTLE support and locking from
Viresh Kumar.
- VIA C7 cpufreq build fix from Rafał Bilski.
- ACPI power management fix making it possible to use device power
states regardless of the CONFIG_PM setting from Rafael J Wysocki.
- New ACPI video blacklist item from Bastian Triller.
* tag 'pm+acpi-3.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: Add "Asus UL30A" to ACPI video detect blacklist
cpufreq: arm_big_little_dt: Instantiate as platform_driver
cpufreq: arm_big_little_dt: Register driver only if DT has valid data
cpufreq / e_powersaver: Fix linker error when ACPI processor is a module
cpufreq / intel_pstate: Add additional supported CPU ID
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT
ACPI / PM: Allow device power states to be used for CONFIG_PM unset
