From eb181c3533e8e5b3eaa96d3e8ed1cf5d9a408076 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Thu, 29 Mar 2012 11:03:27 +0530 Subject: Documentation: pinctrl: add missing spi0_0 grp in example Missed one group from the documentation when proofreading. Signed-off-by: Viresh Kumar 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 d97bccf..f2e27ef 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -640,7 +640,7 @@ struct foo_pmx_func { const unsigned num_groups; }; -static const char * const spi0_groups[] = { "spi0_1_grp" }; +static const char * const spi0_groups[] = { "spi0_0_grp", "spi0_1_grp" }; static const char * const i2c0_groups[] = { "i2c0_grp" }; static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp", "mmc0_3_grp" }; -- cgit v1.1 From 122dbe7e58c7d064a17eefd33205227e6bce85ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Fri, 30 Mar 2012 22:04:51 +0200 Subject: pinctrl: mark const init data with __initconst instead of __initdata MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Uwe Kleine-König Cc: Randy Dunlap 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 f2e27ef..2d88b3c 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -786,7 +786,7 @@ and spi on the second function mapping: #include -static const struct pinctrl_map __initdata mapping[] = { +static const struct pinctrl_map mapping[] __initconst = { { .dev_name = "foo-spi.0", .name = PINCTRL_STATE_DEFAULT, -- cgit v1.1 From d1e90e9e7467dbfe521b25ba79f520bf676ebc36 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Fri, 30 Mar 2012 11:25:40 +0530 Subject: pinctrl: replace list_*() with get_*_count() Most of the SoC drivers implement list_groups() and list_functions() routines for pinctrl and pinmux. These routines continue returning zero until the selector argument is greater than total count of available groups or functions. This patch replaces these list_*() routines with get_*_count() routines, which returns the number of available selection for SoC driver. pinctrl layer will use this value to check the range it can choose. This patch fixes all user drivers for this change. There are other routines in user drivers, which have checks to check validity of selector passed to them. It is also no more required and hence removed. Documentation updated as well. Acked-by: Stephen Warren Signed-off-by: Viresh Kumar [Folded in fix and fixed a minor merge artifact manually] Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 37 +++++++++++++++---------------------- 1 file changed, 15 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 2d88b3c..eb46b1c 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -152,11 +152,9 @@ static const struct foo_group foo_groups[] = { }; -static int foo_list_groups(struct pinctrl_dev *pctldev, unsigned selector) +static int foo_get_groups_count(struct pinctrl_dev *pctldev) { - if (selector >= ARRAY_SIZE(foo_groups)) - return -EINVAL; - return 0; + return ARRAY_SIZE(foo_groups); } static const char *foo_get_group_name(struct pinctrl_dev *pctldev, @@ -175,7 +173,7 @@ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector, } static struct pinctrl_ops foo_pctrl_ops = { - .list_groups = foo_list_groups, + .get_groups_count = foo_get_groups_count, .get_group_name = foo_get_group_name, .get_group_pins = foo_get_group_pins, }; @@ -186,13 +184,12 @@ static struct pinctrl_desc foo_desc = { .pctlops = &foo_pctrl_ops, }; -The pin control subsystem will call the .list_groups() function repeatedly -beginning on 0 until it returns non-zero to determine legal selectors, then -it will call the other functions to retrieve the name and pins of the group. -Maintaining the data structure of the groups is up to the driver, this is -just a simple example - in practice you may need more entries in your group -structure, for example specific register ranges associated with each group -and so on. +The pin control subsystem will call the .get_groups_count() function to +determine total number of legal selectors, then it will call the other functions +to retrieve the name and pins of the group. Maintaining the data structure of +the groups is up to the driver, this is just a simple example - in practice you +may need more entries in your group structure, for example specific register +ranges associated with each group and so on. Pin configuration @@ -606,11 +603,9 @@ static const struct foo_group foo_groups[] = { }; -static int foo_list_groups(struct pinctrl_dev *pctldev, unsigned selector) +static int foo_get_groups_count(struct pinctrl_dev *pctldev) { - if (selector >= ARRAY_SIZE(foo_groups)) - return -EINVAL; - return 0; + return ARRAY_SIZE(foo_groups); } static const char *foo_get_group_name(struct pinctrl_dev *pctldev, @@ -629,7 +624,7 @@ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector, } static struct pinctrl_ops foo_pctrl_ops = { - .list_groups = foo_list_groups, + .get_groups_count = foo_get_groups_count, .get_group_name = foo_get_group_name, .get_group_pins = foo_get_group_pins, }; @@ -663,11 +658,9 @@ static const struct foo_pmx_func foo_functions[] = { }, }; -int foo_list_funcs(struct pinctrl_dev *pctldev, unsigned selector) +int foo_get_functions_count(struct pinctrl_dev *pctldev) { - if (selector >= ARRAY_SIZE(foo_functions)) - return -EINVAL; - return 0; + return ARRAY_SIZE(foo_functions); } const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector) @@ -703,7 +696,7 @@ void foo_disable(struct pinctrl_dev *pctldev, unsigned selector, } struct pinmux_ops foo_pmxops = { - .list_functions = foo_list_funcs, + .get_functions_count = foo_get_functions_count, .get_function_name = foo_get_fname, .get_function_groups = foo_get_groups, .enable = foo_enable, -- cgit v1.1 From c05127c4e2c6e7d9949347a76fd05c337bcd5e84 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 10 Apr 2012 10:00:38 +0200 Subject: pinctrl: implement pinctrl deferred probing If drivers try to obtain pinctrl handles for a pin controller that has not yet registered to the subsystem, we need to be able to back out and retry with deferred probing. So let's return -EPROBE_DEFER whenever this location fails. Also downgrade the errors to info, maybe we will even set them to debug once the deferred probing is commonplace. Cc: Arnd Bergmann Reviewed-by: Mark Brown Acked-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index eb46b1c..4431c3e7 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -1043,6 +1043,11 @@ quickly poking some registers. The pins are allocated for your device when you issue the pinctrl_get() call, after this you should be able to see this in the debugfs listing of all pins. +NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the +requested pinctrl handles, for example if the pinctrl driver has not yet +registered. Thus make sure that the error path in your driver gracefully +cleans up and is ready to retry the probing later in the startup process. + System pin control hogging ========================== -- cgit v1.1 From 7a865277fb0f9da9e456dfc11b0a564cbfc475cd Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 4 Apr 2012 09:27:47 -0600 Subject: dt: pinctrl: Document device tree binding The core pin controller bindings define: * The fact that pin controllers expose pin configurations as nodes in device tree. * That the bindings for those pin configuration nodes is defined by the individual pin controller drivers. * A standardized set of properties for client devices to define numbered or named pin configuration states, each referring to some number of the afore-mentioned pin configuration nodes. * That the bindings for the client devices determines the set of numbered or named states that must exist. Signed-off-by: Stephen Warren Acked-by: Shawn Guo Acked-by: Tony Lindgren Acked-by: Linus Walleij Acked-by: Simon Glass Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-bindings.txt | 128 +++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt new file mode 100644 index 0000000..c95ea82 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -0,0 +1,128 @@ +== Introduction == + +Hardware modules that control pin multiplexing or configuration parameters +such as pull-up/down, tri-state, drive-strength etc are designated as pin +controllers. Each pin controller must be represented as a node in device tree, +just like any other hardware module. + +Hardware modules whose signals are affected by pin configuration are +designated client devices. Again, each client device must be represented as a +node in device tree, just like any other hardware module. + +For a client device to operate correctly, certain pin controllers must +set up certain specific pin configurations. Some client devices need a +single static pin configuration, e.g. set up during initialization. Others +need to reconfigure pins at run-time, for example to tri-state pins when the +device is inactive. Hence, each client device can define a set of named +states. The number and names of those states is defined by the client device's +own binding. + +The common pinctrl bindings defined in this file provide an infrastructure +for client device device tree nodes to map those state names to the pin +configuration used by those states. + +Note that pin controllers themselves may also be client devices of themselves. +For example, a pin controller may set up its own "active" state when the +driver loads. This would allow representing a board's static pin configuration +in a single place, rather than splitting it across multiple client device +nodes. The decision to do this or not somewhat rests with the author of +individual board device tree files, and any requirements imposed by the +bindings for the individual client devices in use by that board, i.e. whether +they require certain specific named states for dynamic pin configuration. + +== Pinctrl client devices == + +For each client device individually, every pin state is assigned an integer +ID. These numbers start at 0, and are contiguous. For each state ID, a unique +property exists to define the pin configuration. Each state may also be +assigned a name. When names are used, another property exists to map from +those names to the integer IDs. + +Each client device's own binding determines the set of states the must be +defined in its device tree node, and whether to define the set of state +IDs that must be provided, or whether to define the set of state names that +must be provided. + +Required properties: +pinctrl-0: List of phandles, each pointing at a pin configuration + node. These referenced pin configuration nodes must be child + nodes of the pin controller that they configure. Multiple + entries may exist in this list so that multiple pin + controllers may be configured, or so that a state may be built + from multiple nodes for a single pin controller, each + contributing part of the overall configuration. See the next + section of this document for details of the format of these + pin configuration nodes. + + In some cases, it may be useful to define a state, but for it + to be empty. This may be required when a common IP block is + used in an SoC either without a pin controller, or where the + pin controller does not affect the HW module in question. If + the binding for that IP block requires certain pin states to + exist, they must still be defined, but may be left empty. + +Optional properties: +pinctrl-1: List of phandles, each pointing at a pin configuration + node within a pin controller. +... +pinctrl-n: List of phandles, each pointing at a pin configuration + node within a pin controller. +pinctrl-names: The list of names to assign states. List entry 0 defines the + name for integer state ID 0, list entry 1 for state ID 1, and + so on. + +For example: + + /* For a client device requiring named states */ + device { + pinctrl-names = "active", "idle"; + pinctrl-0 = <&state_0_node_a>; + pinctrl-1 = <&state_1_node_a &state_1_node_b>; + }; + + /* For the same device if using state IDs */ + device { + pinctrl-0 = <&state_0_node_a>; + pinctrl-1 = <&state_1_node_a &state_1_node_b>; + }; + + /* + * For an IP block whose binding supports pin configuration, + * but in use on an SoC that doesn't have any pin control hardware + */ + device { + pinctrl-names = "active", "idle"; + pinctrl-0 = <>; + pinctrl-1 = <>; + }; + +== Pin controller devices == + +Pin controller devices should contain the pin configuration nodes that client +devices reference. + +For example: + + pincontroller { + ... /* Standard DT properties for the device itself elided */ + + state_0_node_a { + ... + }; + state_1_node_a { + ... + }; + state_1_node_b { + ... + }; + } + +The contents of each of those pin configuration child nodes is defined +entirely by the binding for the individual pin controller device. There +exists no common standard for this content. + +The pin configuration nodes need not be direct children of the pin controller +device; they may be grandchildren, for example. Whether this is legal, and +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. -- cgit v1.1 From e3f80045e8856cb789f0938b61c263249f420ff3 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 4 Apr 2012 09:27:48 -0600 Subject: dt: Move Tegra20 pin mux binding into new pinctrl directory This places the file in the new location for all pin controller bindings. Also, rename the file using the full compatible value for easier avoidance of conflicts between multiple bindings. Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt | 5 +++++ Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt | 5 ----- 2 files changed, 5 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt delete mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt new file mode 100644 index 0000000..36f82db --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt @@ -0,0 +1,5 @@ +NVIDIA Tegra 2 pinmux controller + +Required properties: +- compatible : "nvidia,tegra20-pinmux" + diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt deleted file mode 100644 index 36f82db..0000000 --- a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt +++ /dev/null @@ -1,5 +0,0 @@ -NVIDIA Tegra 2 pinmux controller - -Required properties: -- compatible : "nvidia,tegra20-pinmux" - -- cgit v1.1 From a3c9454e530d51fad49bbc57e19d50a30f94ce14 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 4 Apr 2012 09:27:49 -0600 Subject: dt: Document Tegra20/30 pinctrl binding Define a new binding for the Tegra pin controller, which is capable of defining all aspects of desired pin multiplexing and pin configuration. This is all based on the new common pinctrl bindings. Add Tegra30 binding based on Tegra20 binding. Add some basic stuff that was missing before: * How many and what reg property entries must be provided. * An example. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- .../bindings/pinctrl/nvidia,tegra20-pinmux.txt | 131 +++++++++++++++++++- .../bindings/pinctrl/nvidia,tegra30-pinmux.txt | 132 +++++++++++++++++++++ 2 files changed, 261 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt index 36f82db..c8e5782 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt @@ -1,5 +1,132 @@ -NVIDIA Tegra 2 pinmux controller +NVIDIA Tegra20 pinmux controller Required properties: -- compatible : "nvidia,tegra20-pinmux" +- compatible: "nvidia,tegra20-pinmux" +- reg: Should contain the register physical address and length for each of + the tri-state, mux, pull-up/down, and pad control register sets. +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". + +Tegra's pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, tristate, drive strength, etc. + +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 or tristate parameter. For this +reason, even seemingly boolean values are actually tristates in this binding: +unspecified, off, or on. Unspecified is represented as an absent property, +and off/on are represented as integer values 0 and 1. + +Required subnode-properties: +- nvidia,pins : An array of strings. Each string contains the name of a pin or + group. Valid values for these names are listed below. + +Optional subnode-properties: +- nvidia,function: A string containing the name of the function to mux to the + pin or group. Valid values for function names are listed below. See the Tegra + TRM to determine which are valid for each pin or group. +- nvidia,pull: Integer, representing the pull-down/up to apply to the pin. + 0: none, 1: down, 2: up. +- nvidia,tristate: Integer. + 0: drive, 1: tristate. +- nvidia,high-speed-mode: Integer. Enable high speed mode the pins. + 0: no, 1: yes. +- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input. + 0: no, 1: yes. +- nvidia,low-power-mode: Integer. Valid values 0-3. 0 is least power, 3 is + most power. Controls the drive power or current. See "Low Power Mode" + or "LPMD1" and "LPMD0" in the Tegra TRM. +- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest. + The range of valid values depends on the pingroup. See "CAL_DRVDN" in the + Tegra TRM. +- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest. + The range of valid values depends on the pingroup. See "CAL_DRVUP" in the + Tegra TRM. +- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is + fastest. The range of valid values depends on the pingroup. See + "DRVDN_SLWR" in the Tegra TRM. +- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is + fastest. The range of valid values depends on the pingroup. See + "DRVUP_SLWF" in the Tegra TRM. + +Note that many of these properties are only valid for certain specific pins +or groups. See the Tegra TRM and various pinmux spreadsheets for complete +details regarding which groups support which functionality. The Linux pinctrl +driver may also be a useful reference, since it consolidates, disambiguates, +and corrects data from all those sources. + +Valid values for pin and group names are: + + mux groups: + + These all support nvidia,function, nvidia,tristate, and many support + nvidia,pull. + + ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1, dap2, dap3, dap4, + ddc, dta, dtb, dtc, dtd, dte, dtf, gma, gmb, gmc, gmd, gme, gpu, gpu7, + gpv, hdint, i2cp, irrx, irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn, + ld0, ld1, ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12, ld13, + ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2, lhs, lm0, lm1, lpp, + lpw0, lpw1, lpw2, lsc0, lsc1, lsck, lsda, lsdi, lspi, lvp0, lvp1, lvs, + owc, pmc, pta, rm, sdb, sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi, + spdo, spia, spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac, uad, + uca, ucb, uda. + + tristate groups: + + These only support nvidia,pull. + + ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls, lc, ld17_0, + ld19_18, ld21_20, ld23_22. + + drive groups: + + With some exceptions, these support nvidia,high-speed-mode, + nvidia,schmitt, nvidia,low-power-mode, nvidia,pull-down-strength, + nvidia,pull-up-strength, nvidia,slew_rate-rising, nvidia,slew_rate-falling. + + drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, drive_cdev2, + drive_csus, drive_dap1, drive_dap2, drive_dap3, drive_dap4, drive_dbg, + drive_lcd1, drive_lcd2, drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa, + drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2, drive_xm2a, + drive_xm2c, drive_xm2d, drive_xm2clk, drive_sdio1, drive_crt, drive_ddc, + drive_gma, drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_owr, + drive_uda. + +Example: + + pinctrl@70000000 { + compatible = "nvidia,tegra20-pinmux"; + reg = < 0x70000014 0x10 /* Tri-state registers */ + 0x70000080 0x20 /* Mux registers */ + 0x700000a0 0x14 /* Pull-up/down registers */ + 0x70000868 0xa8 >; /* Pad control registers */ + }; + +Example board file extract: + + pinctrl@70000000 { + sdio4_default: sdio4_default { + atb { + nvidia,pins = "atb", "gma", "gme"; + nvidia,function = "sdio4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + }; + }; + + sdhci@c8000600 { + pinctrl-names = "default"; + pinctrl-0 = <&sdio4_default>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt new file mode 100644 index 0000000..c275b70 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt @@ -0,0 +1,132 @@ +NVIDIA Tegra30 pinmux controller + +The Tegra30 pinctrl binding is very similar to the Tegra20 pinctrl binding, +as described in nvidia,tegra20-pinmux.txt. In fact, this document assumes +that binding as a baseline, and only documents the differences between the +two bindings. + +Required properties: +- compatible: "nvidia,tegra30-pinmux" +- reg: Should contain the register physical address and length for each of + the pad control and mux registers. + +Tegra30 adds the following optional properties for pin configuration subnodes: +- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes. +- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes. +- nvidia,lock: Integer. Lock the pin configuration against further changes + until reset. 0: no, 1: yes. +- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes. + +As with Tegra20, see the Tegra TRM for complete details regarding which groups +support which functionality. + +Valid values for pin and group names are: + + per-pin mux groups: + + These all support nvidia,function, nvidia,tristate, nvidia,pull, + nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain, + nvidia,io-reset. + + clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2, dap2_sclk_pa3, + dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, gmi_a17_pb0, + gmi_a18_pb1, lcd_pwr0_pb2, lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5, + sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0, lcd_pwr1_pc1, + uart2_txd_pc2, uart2_rxd_pc3, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, + lcd_pwr2_pc6, gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1, lcd_dc1_pd2, + sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5, vi_vsync_pd6, vi_hsync_pd7, + lcd_d0_pe0, lcd_d1_pe1, lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5, + lcd_d6_pe6, lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2, lcd_d11_pf3, + lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6, lcd_d15_pf7, gmi_ad0_pg0, + gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, + gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, + gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7, + gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2, gmi_cs6_n_pi3, gmi_rst_n_pi4, + gmi_iordy_pi5, gmi_cs7_n_pi6, gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1, + gmi_cs1_n_pj2, lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5, + uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs4_n_pk2, + gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5, spdif_in_pk6, gmi_a19_pk7, + vi_d2_pl0, vi_d3_pl1, vi_d4_pl2, vi_d5_pl3, vi_d6_pl4, vi_d7_pl5, + vi_d8_pl6, vi_d9_pl7, lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3, + lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7, dap1_fs_pn0, + dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, lcd_cs0_n_pn4, lcd_sdout_pn5, + lcd_dc0_pn6, hdmi_int_pn7, ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2, + ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6, + ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, + dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0, + kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, + kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, + kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, + kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, + kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1, + vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, + sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4, pu5, pu6, jtag_rtck_pu7, pv0, + pv1, pv2, pv3, ddc_scl_pv4, ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7, + lcd_cs1_n_pw0, lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4, + clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0, spi2_miso_px1, + spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4, spi1_sck_px5, spi1_cs0_n_px6, + spi1_miso_px7, ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, + sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7, + sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3, lcd_sck_pz4, + sys_clk_req_pz5, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, sdmmc4_dat0_paa0, + sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, + sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0, + cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, + cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3, sdmmc4_clk_pcc4, + clk2_req_pcc5, pex_l2_rst_n_pcc6, pex_l2_clkreq_n_pcc7, + pex_l0_prsnt_n_pdd0, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2, + pex_wake_n_pdd3, pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5, + pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0, clk3_req_pee1, + clk1_req_pee2, hdmi_cec_pee3, clk_32k_in, core_pwr_req, cpu_pwr_req, owr, + pwr_int_n. + + drive groups: + + These all support nvidia,pull-down-strength, nvidia,pull-up-strength, + nvidia,slew_rate-rising, nvidia,slew_rate-falling. Most but not all + support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode. + + ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, cec, crt, csus, dap1, + dap2, dap3, dap4, dbg, ddc, dev3, gma, gmb, gmc, gmd, gme, gmf, gmg, + gmh, gpv, lcd1, lcd2, owr, sdio1, sdio2, sdio3, spi, uaa, uab, uart2, + uart3, uda, vi1. + +Example: + + pinctrl@70000000 { + compatible = "nvidia,tegra30-pinmux"; + reg = < 0x70000868 0xd0 /* Pad control registers */ + 0x70003000 0x3e0 >; /* Mux registers */ + }; + +Example board file extract: + + pinctrl@70000000 { + sdmmc4_default: pinmux { + sdmmc4_clk_pcc4 { + nvidia,pins = "sdmmc4_clk_pcc4", + "sdmmc4_rst_n_pcc3"; + nvidia,function = "sdmmc4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + sdmmc4_dat0_paa0 { + nvidia,pins = "sdmmc4_dat0_paa0", + "sdmmc4_dat1_paa1", + "sdmmc4_dat2_paa2", + "sdmmc4_dat3_paa3", + "sdmmc4_dat4_paa4", + "sdmmc4_dat5_paa5", + "sdmmc4_dat6_paa6", + "sdmmc4_dat7_paa7"; + nvidia,function = "sdmmc4"; + nvidia,pull = <2>; + nvidia,tristate = <0>; + }; + }; + }; + + sdhci@78000400 { + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc4_default>; + }; -- cgit v1.1 From 6d4ca1fb467932773da7b808c52f3d7ef4461ba0 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Mon, 16 Apr 2012 10:51:00 -0600 Subject: pinctrl: implement devm_pinctrl_get()/put() These functions allow the driver core to automatically clean up any allocations made by drivers, thus leading to simplified drivers. Signed-off-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/driver-model/devres.txt | 4 +++ Documentation/pinctrl.txt | 48 +++++++++++++++++++++-------------- 2 files changed, 33 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 2a596a4..ef4fa7b 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -276,3 +276,7 @@ REGULATOR devm_regulator_get() devm_regulator_put() devm_regulator_bulk_get() + +PINCTRL + devm_pinctrl_get() + devm_pinctrl_put() diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 4431c3e7..e40f4b4 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -945,13 +945,13 @@ case), we define a mapping like this: The result of grabbing this mapping from the device with something like this (see next paragraph): - p = pinctrl_get(dev); + p = devm_pinctrl_get(dev); s = pinctrl_lookup_state(p, "8bit"); ret = pinctrl_select_state(p, s); or more simply: - p = pinctrl_get_select(dev, "8bit"); + p = devm_pinctrl_get_select(dev, "8bit"); Will be that you activate all the three bottom records in the mapping at once. Since they share the same name, pin controller device, function and @@ -985,7 +985,7 @@ foo_probe() /* Allocate a state holder named "foo" etc */ struct foo_state *foo = ...; - foo->p = pinctrl_get(&device); + foo->p = devm_pinctrl_get(&device); if (IS_ERR(foo->p)) { /* FIXME: clean up "foo" here */ return PTR_ERR(foo->p); @@ -993,24 +993,17 @@ foo_probe() foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT); if (IS_ERR(foo->s)) { - pinctrl_put(foo->p); /* FIXME: clean up "foo" here */ return PTR_ERR(s); } ret = pinctrl_select_state(foo->s); if (ret < 0) { - pinctrl_put(foo->p); /* FIXME: clean up "foo" here */ return ret; } } -foo_remove() -{ - pinctrl_put(state->p); -} - This get/lookup/select/put sequence can just as well be handled by bus drivers if you don't want each and every driver to handle it and you know the arrangement on your bus. @@ -1022,6 +1015,11 @@ The semantics of the pinctrl APIs are: kernel memory to hold the pinmux state. All mapping table parsing or similar slow operations take place within this API. +- devm_pinctrl_get() is a variant of pinctrl_get() that causes pinctrl_put() + to be called automatically on the retrieved pointer when the associated + device is removed. It is recommended to use this function over plain + pinctrl_get(). + - pinctrl_lookup_state() is called in process context to obtain a handle to a specific state for a the client device. This operation may be slow too. @@ -1034,14 +1032,25 @@ The semantics of the pinctrl APIs are: - pinctrl_put() frees all information associated with a pinctrl handle. +- devm_pinctrl_put() is a variant of pinctrl_put() that may be used to + explicitly destroy a pinctrl object returned by devm_pinctrl_get(). + However, use of this function will be rare, due to the automatic cleanup + that will occur even without calling it. + + pinctrl_get() must be paired with a plain pinctrl_put(). + pinctrl_get() may not be paired with devm_pinctrl_put(). + devm_pinctrl_get() can optionally be paired with devm_pinctrl_put(). + devm_pinctrl_get() may not be paired with plain pinctrl_put(). + Usually the pin control core handled the get/put pair and call out to the device drivers bookkeeping operations, like checking available functions and the associated pins, whereas the enable/disable pass on to the pin controller driver which takes care of activating and/or deactivating the mux setting by quickly poking some registers. -The pins are allocated for your device when you issue the pinctrl_get() call, -after this you should be able to see this in the debugfs listing of all pins. +The pins are allocated for your device when you issue the devm_pinctrl_get() +call, after this you should be able to see this in the debugfs listing of all +pins. NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the requested pinctrl handles, for example if the pinctrl driver has not yet @@ -1092,13 +1101,13 @@ it, disables and releases it, and muxes it in on the pins defined by group B: #include -foo_switch() -{ - struct pinctrl *p; - struct pinctrl_state *s1, *s2; +struct pinctrl *p; +struct pinctrl_state *s1, *s2; +foo_probe() +{ /* Setup */ - p = pinctrl_get(&device); + p = devm_pinctrl_get(&device); if (IS_ERR(p)) ... @@ -1109,7 +1118,10 @@ foo_switch() s2 = pinctrl_lookup_state(foo->p, "pos-B"); if (IS_ERR(s2)) ... +} +foo_switch() +{ /* Enable on position A */ ret = pinctrl_select_state(s1); if (ret < 0) @@ -1123,8 +1135,6 @@ foo_switch() ... ... - - pinctrl_put(p); } The above has to be done from process context. -- cgit v1.1