summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c
Commit message (Collapse)AuthorAgeLines
* pinctrl: uniphier: support pin configurationMasahiro Yamada2017-02-23-1/+2
| | | | | | | | | | | | | | | | | Support the following DT properties: "bias-disable" "bias-pull-up" "bias-pull-down" "bias-pull-pin-default" "input-enable" "input-disable" My main motivation is to support pull up/down biasing. For Pro5 and later SoCs, the pupdctrl register number is the same as the pinmux number, so this feature can be supported without having big pin tables. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* pinctrl: uniphier: add System Bus pin-mux settingsMasahiro Yamada2016-09-14-0/+30
| | | | | | This is needed to get access to UniPhier System Bus (external bus). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: use (devm_)ioremap() instead of map_sysmem()Masahiro Yamada2016-07-24-2/+2
| | | | | | | | This does not have much impact on behavior, but makes code look more more like Linux. The use of devm_ioremap() often helps to delete .remove callbacks entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* pinctrl: uniphier: avoid building unneeded pin-mux tables for SPLMasahiro Yamada2016-07-02-23/+23
| | | | | | | SPL does not use all of the devices, so we can save some memory footprint. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* pinctrl: uniphier: support pin configuration for dedicated pinsMasahiro Yamada2016-07-02-22/+21
| | | | | | | | | | | | | | PH1-LD4 and PH1-sLD8 SoCs have pins that support pin configuration (pin biasing, drive strength control), but not pin-muxing. Allow to fill the mux value table with -1 for those pins; pins with mux value -1 will be skipped in the pin-mux set function. The mux value type should be changed from "unsigned" to "int" in order to accommodate -1 as a special case. [ Linux commit: 363c90e743b50a432a91a211dd8b078d9df446e9 ] Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* pinctrl: uniphier: allow to have pinctrl node under syscon nodeMasahiro Yamada2016-07-02-1/+1
| | | | | | | | | | | Currently, the UniPhier pinctrl driver itself is a syscon, but it turned out much more reasonable to make it a child node of a syscon because our syscon node consists of a bunch of system configuration registers, not only pinctrl, but also phy, and misc registers. It is difficult to split the node. This commit allows to migrate to the new DT structure. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* pinctrl: uniphier: rename function/array namesMasahiro Yamada2016-04-24-17/+17
| | | | | | Make function/array names match the file names for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* pinctrl: uniphier: introduce capability flagMasahiro Yamada2016-04-01-3/+1
| | | | | | | | | | | | | | | | | | | | | The core part of the UniPhier pinctrl driver needs to support a new capability for upcoming UniPhier ARMv8 SoCs. This sometimes happens because pinctrl drivers include really SoC-specific stuff. This commit intends to tidy up SoC-specific parameters of the existing drivers before adding new ones. Having flags would be better than adding new members every time a new SoC-specific capability comes up. At this time, there is one flag, UNIPHIER_PINCTRL_CAPS_DBGMUX_SEPARATE. This capability (I'd say rather quirk) was added for PH1-Pro4 and PH1-Pro5 as requirement from our customer. For those SoCs, one pin-mux setting is controlled by the combination of two separate registers; the LSB bits at register offset (8 * N) and the MSB bits at (8 * N + 4). Because it is impossible to update two separate registers atomically, the LOAD_PINCTRL register should be set in order to make the pin-mux settings really effective. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: drop PH1- prefix from CONFIG options and file namesMasahiro Yamada2016-03-24-0/+144
The current CONFIG names like "CONFIG_ARCH_UNIPHIER_PH1_PRO4" is too long. It would not hurt to drop "PH1_" because "UNIPHIER_" already well specifies the SoC family. Also, rename files for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>