From eb6002d5e2eaf8b8c0ee11c8e47bbe7473b4c434 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 25 Jun 2013 16:17:15 +0200 Subject: pinctrl: elaborate a bit on arrangements in doc This elaborates a bit on the pin control and pin muxing logic vs GPIO arangements in the hardware. Inspired by some drawings in a mail from Christian Ruppert. Both arrangements are confirmed to exist in practice. Cc: Rob Landley Reviewed-by: Christian Ruppert Reviewed-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 91 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 85 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 052e13af2d38..d2d7fc05a8fd 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -795,18 +795,97 @@ special GPIO-handler is registered. GPIO mode pitfalls ================== -Sometime the developer may be confused by a datasheet talking about a pin -being possible to set into "GPIO mode". It appears that what hardware -engineers mean with "GPIO mode" is not necessarily the use case that is -implied in the kernel interface : a pin that you grab from -kernel code and then either listen for input or drive high/low to -assert/deassert some external line. +Due to the naming conventions used by hardware engineers, where "GPIO" +is taken to mean different things than what the kernel does, the developer +may be confused by a datasheet talking about a pin being possible to set +into "GPIO mode". It appears that what hardware engineers mean with +"GPIO mode" is not necessarily the use case that is implied in the kernel +interface : a pin that you grab from kernel code and then +either listen for input or drive high/low to assert/deassert some +external line. Rather hardware engineers think that "GPIO mode" means that you can software-control a few electrical properties of the pin that you would not be able to control if the pin was in some other mode, such as muxed in for a device. +The GPIO portions of a pin and its relation to a certain pin controller +configuration and muxing logic can be constructed in several ways. Here +are two examples: + +(A) + pin config + logic regs + | +- SPI + Physical pins --- pad --- pinmux -+- I2C + | +- mmc + | +- GPIO + pin + multiplex + logic regs + +Here some electrical properties of the pin can be configured no matter +whether the pin is used for GPIO or not. If you multiplex a GPIO onto a +pin, you can also drive it high/low from "GPIO" registers. +Alternatively, the pin can be controlled by a certain peripheral, while +still applying desired pin config properties. GPIO functionality is thus +orthogonal to any other device using the pin. + +In this arrangement the registers for the GPIO portions of the pin controller, +or the registers for the GPIO hardware module are likely to reside in a +separate memory range only intended for GPIO driving, and the register +range dealing with pin config and pin multiplexing get placed into a +different memory range and a separate section of the data sheet. + +(B) + + pin config + logic regs + | +- SPI + Physical pins --- pad --- pinmux -+- I2C + | | +- mmc + | | + GPIO pin + multiplex + logic regs + +In this arrangement, the GPIO functionality can always be enabled, such that +e.g. a GPIO input can be used to "spy" on the SPI/I2C/MMC signal while it is +pulsed out. It is likely possible to disrupt the traffic on the pin by doing +wrong things on the GPIO block, as it is never really disconnected. It is +possible that the GPIO, pin config and pin multiplex registers are placed into +the same memory range and the same section of the data sheet, although that +need not be the case. + +From a kernel point of view, however, these are different aspects of the +hardware and shall be put into different subsystems: + +- Registers (or fields within registers) that control electrical + properties of the pin such as biasing and drive strength should be + exposed through the pinctrl subsystem, as "pin configuration" settings. + +- Registers (or fields within registers) that control muxing of signals + from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should + be exposed through the pinctrl subssytem, as mux functions. + +- Registers (or fields within registers) that control GPIO functionality + such as setting a GPIO's output value, reading a GPIO's input value, or + setting GPIO pin direction should be exposed through the GPIO subsystem, + and if they also support interrupt capabilities, through the irqchip + abstraction. + +Depending on the exact HW register design, some functions exposed by the +GPIO subsystem may call into the pinctrl subsystem in order to +co-ordinate register settings across HW modules. In particular, this may +be needed for HW with separate GPIO and pin controller HW modules, where +e.g. GPIO direction is determined by a register in the pin controller HW +module rather than the GPIO HW module. + +Electrical properties of the pin such as biasing and drive strength +may be placed at some pin-specific register in all cases or as part +of the GPIO register in case (B) especially. This doesn't mean that such +properties necessarily pertain to what the Linux kernel calls "GPIO". + Example: a pin is usually muxed in to be used as a UART TX line. But during system sleep, we need to put this pin into "GPIO mode" and ground it. -- cgit v1.2.3 From bcd0c8c2d4daf13a41880a82a685de41e6e193cc Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Mon, 5 Aug 2013 15:55:59 -0600 Subject: pinctrl: clean up pinconfig-generic documentation Reword the section of pinctrl-bindings.txt that describes generic properties that pinctrl bindings may use. The aim is to make the text clearer, and more explicitly call out the responsibility of individual bindings that use the generic properties to define which of the properties are used, and how. Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-bindings.txt | 25 +++++++++------------- 1 file changed, 10 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index aeb3c995cc04..31b0cb9de4f2 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -127,20 +127,16 @@ whether there is any interaction between the child and intermediate parent nodes, is again defined entirely by the binding for the individual pin controller device. -== Using generic pinconfig options == +== Generic pin configuration node content == -Generic pinconfig parameters can be used by defining a separate node containing -the applicable parameters (and optional values), like: +Many data items that are represented in a pin configuration node are common +and generic. Pin control bindings should use the properties defined below +where they are applicable; not all of these properties are relevant or useful +for all hardware or binding structures. Each individual binding document +should state which of these generic properties, if any, are used, and the +structure of the DT nodes that contain these properties. -pcfg_pull_up: pcfg_pull_up { - bias-pull-up; - drive-strength = <20>; -}; - -This node should then be referenced in the appropriate pinctrl node as a phandle -and parsed in the driver using the pinconf_generic_parse_dt_config function. - -Supported configuration parameters are: +Supported generic properties are: bias-disable - disable any pin bias bias-high-impedance - high impedance mode ("third-state", "floating") @@ -160,7 +156,8 @@ low-power-disable - disable low power mode output-low - set the pin to output mode with low level output-high - set the pin to output mode with high level -Arguments for parameters: +Some of the generic properties take arguments. For those that do, the +arguments are described below. - bias-pull-up, -down and -pin-default take as optional argument on hardware supporting it the pull strength in Ohm. bias-disable will disable the pull. @@ -170,7 +167,5 @@ Arguments for parameters: - input-debounce takes the debounce time in usec as argument or 0 to disable debouncing -All parameters not listed here, do not take an argument. - More in-depth documentation on these parameters can be found in -- cgit v1.2.3 From 87311d0455fb92cb6ad5ef539c9351a22c02e53a Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Tue, 6 Aug 2013 11:10:32 -0600 Subject: pinctrl: add generic pins and functions properties pinctrl bindings can benefit from generic property names that define which pins a "pin configuration node" affects, and which mux function to select onto those pins. Document new properties for this purpose so that other bindings may refer to them. Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/pinctrl-bindings.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 31b0cb9de4f2..1958ca9f9e5c 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -138,6 +138,9 @@ structure of the DT nodes that contain these properties. Supported generic properties are: +pins - the list of pins that properties in the node + apply to +function - the mux function to select bias-disable - disable any pin bias bias-high-impedance - high impedance mode ("third-state", "floating") bias-bus-hold - latch weakly @@ -159,6 +162,19 @@ output-high - set the pin to output mode with high level Some of the generic properties take arguments. For those that do, the arguments are described below. +- pins takes a list of pin names or IDs as a required argument. The specific + binding for the hardware defines: + - Whether the entries are integers or strings, and their meaning. + +- function takes a list of function names/IDs as a required argument. The + specific binding for the hardware defines: + - Whether the entries are integers or strings, and their meaning. + - Whether only a single entry is allowed (which is applied to all entries + in the pins property), or whether there may alternatively be one entry per + entry in the pins property, in which case the list lengths must match, and + for each list index i, the function at list index i is applied to the pin + at list index i. + - bias-pull-up, -down and -pin-default take as optional argument on hardware supporting it the pull strength in Ohm. bias-disable will disable the pull. -- cgit v1.2.3 From 0a8d3e2412841c6b1dab1006fd5f7ab5b689db21 Mon Sep 17 00:00:00 2001 From: Laxman Dewangan Date: Tue, 6 Aug 2013 18:42:35 +0530 Subject: pinctrl: palmas: add pincontrol driver TI Palmas series Power Management IC have multiple pins which can be configured for different functionality. This pins can be configured for different function. Also their properties like pull up/down, open drain enable/disable are configurable. Add support for pincontrol driver Palmas series device like TPS65913, TPS80036. The driver supports to be register from DT only. Changes from V1: - Add generic property for pins and functions in pinconf-generic. - Add APIs to map the DT and subnode. - Move common utils APIs to the pinctrl-utils from this file. - Update the binding document accordingly. Changes from V2: - Add ack by Lee. - Correct the binding docs. Signed-off-by: Laxman Dewangan Acked-by: Lee Jones Reviewed-by: Stephen Warren Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/pinctrl-palmas.txt | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt new file mode 100644 index 000000000000..734d9b04d533 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt @@ -0,0 +1,96 @@ +Palmas Pincontrol bindings + +The pins of Palmas device can be set on different option and provides +the configuration for Pull UP/DOWN, open drain etc. + +Required properties: +- compatible: It must be one of following: + - "ti,palmas-pinctrl" for Palma series of the pincontrol. + - "ti,tps65913-pinctrl" for Palma series device TPS65913. + - "ti,tps80036-pinctrl" for Palma series device TPS80036. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Palmas's pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +list of pins. This configuration can include the mux function to select on +those pin(s), and various pin configuration parameters, such as pull-up, +open drain. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +Optional properties: +- ti,palmas-enable-dvfs1: Enable DVFS1. Configure pins for DVFS1 mode. + Selection primary or secondary function associated to I2C2_SCL_SCE, + I2C2_SDA_SDO pin/pad for DVFS1 interface +- ti,palmas-enable-dvfs2: Enable DVFS2. Configure pins for DVFS2 mode. + Selection primary or secondary function associated to GPADC_START + and SYSEN2 pin/pad for DVFS2 interface + +This binding uses the following generic properties as defined in +pinctrl-bindings.txt: + +Required: pins +Options: function, bias-disable, bias-pull-up, bias-pull-down, + bias-pin-default, drive-open-drain. + +Note that many of these properties are only valid for certain specific pins. +See the Palmas device datasheet for complete details regarding which pins +support which functionality. + +Valid values for pin names are: + gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8, gpio9, + gpio10, gpio11, gpio12, gpio13, gpio14, gpio15, vac, powergood, + nreswarm, pwrdown, gpadc_start, reset_in, nsleep, enable1, enable2, + int. + +Valid value of function names are: + gpio, led, pwm, regen, sysen, clk32kgaudio, id, vbus_det, chrg_det, + vac, vacok, powergood, usb_psel, msecure, pwrhold, int, nreswarm, + simrsto, simrsti, low_vbat, wireless_chrg1, rcm, pwrdown, gpadc_start, + reset_in, nsleep, enable. + +There are 4 special functions: opt0, opt1, opt2 and opt3. If any of these +functions is selected then directly pins register will be written with 0, 1, 2 +or 3 respectively if it is valid for that pins or list of pins. + +Example: + palmas: tps65913 { + .... + pinctrl { + compatible = "ti,tps65913-pinctrl"; + ti,palmas-enable-dvfs1; + pinctrl-names = "default"; + pinctrl-0 = <&palmas_pins_state>; + + palmas_pins_state: pinmux { + gpio0 { + pins = "gpio0"; + function = "id"; + bias-pull-up; + }; + + vac { + pins = "vac"; + function = "vacok"; + bias-pull-down; + }; + + gpio5 { + pins = "gpio5"; + function = "opt0"; + drive-open-drain = <1>; + }; + }; + }; + .... + }; -- cgit v1.2.3 From 2868a07446e435fa74a6543da857a494d2930a99 Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Thu, 8 Aug 2013 10:50:59 +0530 Subject: Documentation: pinctrl: Fix example code __initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Fix the examples. Signed-off-by: Sachin Kamat Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index d2d7fc05a8fd..e7bee9bab032 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -935,7 +935,7 @@ static unsigned long uart_sleep_mode[] = { PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0), }; -static struct pinctrl_map __initdata pinmap[] = { +static struct pinctrl_map pinmap[] __initdata = { PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "u0_group", "u0"), PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo", @@ -1030,7 +1030,7 @@ Since the above construct is pretty common there is a helper macro to make it even more compact which assumes you want to use pinctrl-foo and position 0 for mapping, for example: -static struct pinctrl_map __initdata mapping[] = { +static struct pinctrl_map mapping[] __initdata = { PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT, "pinctrl-foo", NULL, "i2c0"), }; @@ -1049,7 +1049,7 @@ static unsigned long i2c_pin_configs[] = { FOO_SLEW_RATE_SLOW, }; -static struct pinctrl_map __initdata mapping[] = { +static struct pinctrl_map mapping[] __initdata = { PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"), PIN_MAP_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs), PIN_MAP_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs), @@ -1063,7 +1063,7 @@ order to explicitly indicate that the states were provided and intended to be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining a named state without causing any pin controller to be programmed: -static struct pinctrl_map __initdata mapping[] = { +static struct pinctrl_map mapping[] __initdata = { PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT), }; -- cgit v1.2.3 From a1bc260bb5f5d95da854be7898202d788e94448d Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Fri, 9 Aug 2013 10:57:46 -0600 Subject: gpio: clean up gpio-ranges documentation This change makes documentation of the the gpio-ranges property shorter and more succinct, more consistent with the style of the rest of the document, and not mention Linux-specifics such as the API pinctrl_request_gpio(); DT binding documents should be OS independant where at all possible. As part of this, the gpio-ranges property's format is described in BNF form, in order to match the rest of the document. This change also deprecates the #gpio-range-cells property. Such properties are useful when one node references a second node, and that second node dictates the format of the reference. However, that is not the case here; the definition of gpio-ranges itself always dictates its format entirely, and hence the value #gpio-range-cells must always be 3, and hence there is no point requiring any referenced node to include this property. The only remaining need for this property is to ensure compatibility of DTs with older SW that was written to support the previous version of the binding. v4: * Mention #gpio-range-cells as being deprecated, rather than removing all documentation of that property. This allows DTs to be written in a backwards-compatible way if desired, and also allows older DTs to be interpreted fully using the latest documentation. v3: * Mention BNF in commit description. * Fixed typo. * Dropped patch that removed the deprecated property from *.dts, since it's required to boot older kernels. Signed-off-by: Stephen Warren Acked-by: Mark Rutland Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/gpio/gpio.txt | 55 ++++++++++++++----------- 1 file changed, 30 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index d933af370697..6cec6ff20d2e 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -75,23 +75,36 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: gpio-controller; }; -2.1) gpio-controller and pinctrl subsystem ------------------------------------------- +2.1) gpio- and pin-controller interaction +----------------------------------------- -gpio-controller on a SOC might be tightly coupled with the pinctrl -subsystem, in the sense that the pins can be used by other functions -together with optional gpio feature. +Some or all of the GPIOs provided by a GPIO controller may be routed to pins +on the package via a pin controller. This allows muxing those pins between +GPIO and other functions. -While the pin allocation is totally managed by the pin ctrl subsystem, -gpio (under gpiolib) is still maintained by gpio drivers. It may happen -that different pin ranges in a SoC is managed by different gpio drivers. +It is useful to represent which GPIOs correspond to which pins on which pin +controllers. The gpio-ranges property described below represents this, and +contains information structures as follows: -This makes it logical to let gpio drivers announce their pin ranges to -the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to -request the corresponding pin before any gpio usage. + gpio-range-list ::= [gpio-range-list] + single-gpio-range ::= + + gpio-phandle : phandle to pin controller node. + gpio-base : Base GPIO ID in the GPIO controller + pinctrl-base : Base pinctrl pin ID in the pin controller + count : The number of GPIOs/pins in this range -For this, the gpio controller can use a pinctrl phandle and pins to -announce the pinrange to the pin ctrl subsystem. For example, +The "pin controller node" mentioned above must conform to the bindings +described in ../pinctrl/pinctrl-bindings.txt. + +Previous versions of this binding required all pin controller nodes that +were referenced by any gpio-ranges property to contain a property named +#gpio-range-cells with value <3>. This requirement is now deprecated. +However, that property may still exist in older device trees for +compatibility reasons, and would still be required even in new device +trees that need to be compatible with older software. + +Example: qe_pio_e: gpio-controller@1460 { #gpio-cells = <2>; @@ -99,16 +112,8 @@ announce the pinrange to the pin ctrl subsystem. For example, reg = <0x1460 0x18>; gpio-controller; gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>; + }; - } - -where, - &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node. - - Next values specify the base pin and number of pins for the range - handled by 'qe_pio_e' gpio. In the given example from base pin 20 to - pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under - pinctrl2 with gpio offset 10 is handled by this gpio controller. - -The pinctrl node must have "#gpio-range-cells" property to show number of -arguments to pass with phandle from gpio controllers node. +Here, a single GPIO controller has GPIOs 0..9 routed to pin controller +pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's +pins 50..59. -- cgit v1.2.3 From e2b86b8481502f3f3039a31aa1a85b8a29e246f1 Mon Sep 17 00:00:00 2001 From: Axel Lin Date: Sun, 18 Aug 2013 20:43:33 +0800 Subject: Documentation: pinctrl: Fix example code for pinctrl_register pinctrl_register() returns NULL on error, fix it. Signed-off-by: Axel Lin Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index e7bee9bab032..c0ffd30eb55e 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -81,7 +81,7 @@ int __init foo_probe(void) struct pinctrl_dev *pctl; pctl = pinctrl_register(&foo_desc, , NULL); - if (IS_ERR(pctl)) + if (!pctl) pr_err("could not register foo pin driver\n"); } -- cgit v1.2.3 From 608a26a7bc04a39cfd7041f31ca2b2100113d14e Mon Sep 17 00:00:00 2001 From: Mateusz Krawczuk Date: Tue, 27 Aug 2013 15:08:10 +0200 Subject: pinctrl: Add s5pv210 support to pinctrl-exynos This patch implements pinctrl support and adds device tree bindings for s5pv210. Signed-off-by: Mateusz Krawczuk Acked-by: Sylwester Nawrocki Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 36281e7a2a46..257677de3e6b 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -12,6 +12,7 @@ Required Properties: - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, + - "samsung,s5pv210-pinctrl": for S5PV210-compatible pin-controller, - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. @@ -128,7 +129,7 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller found on Samsung S3C64xx SoCs, - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller - found on Samsung Exynos4210 SoC. + found on Samsung Exynos4210 and S5PC110/S5PV210 SoCs. - interrupt-parent: phandle of the interrupt parent to which the external wakeup interrupts are forwarded to. - interrupts: interrupt used by multiplexed wakeup interrupts. -- cgit v1.2.3