summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/uniphier/pinctrl-uniphier.h
AgeCommit message (Collapse)Author
2017-02-22pinctrl: uniphier: support pin configurationMasahiro Yamada
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>
2016-10-18pinctrl: uniphier: fix unused-const-variable warnings for GCC 6.xMasahiro Yamada
Marek reports warnings in UniPhier pinctrl drivers when compiled by GCC 6.x, like: drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c:58:18: warning: 'usb3_muxvals' defined but not used [-Wunused-const-variable=] static const int usb3_muxvals[] = {0, 0}; ^~~~~~~~~~~~ My intention here is to compile minimum set of pin data for SPL to save memory footprint, but GCC these days is clever enough to notice unused data arrays. We can fix it by sprinkling around __maybe_unused on those arrays, but I did not do that because they are counterparts of the pinctrl drivers in Linux. All the pin data were just copy-pasted from Linux and are kept in sync for maintainability. I chose a bit tricky way to fix the issue; calculate ARRAY_SIZE of *_pins and *_muxvals and set their sum to an unused struct member. This trick will satisfy GCC because the data arrays are used anyway, but such data arrays will be dropped from the final binary because the pointers to them are not used. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reported-by: Marek Vasut <marex@denx.de>
2016-09-18pinctrl: uniphier: support 4bit-width pin-mux register capabilityMasahiro Yamada
On LD4 SoC or later, the pin-mux registers are 8bit wide, while 4bit wide on sLD3 SoC. Support it for the sLD3 pinctrl driver. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-09-14pinctrl: uniphier: move register base macros from header to .c fileMasahiro Yamada
These macros are only referenced in pinctrl-uniphier-core.c, so they need not reside in a header file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-07-23ARM: uniphier: use (devm_)ioremap() instead of map_sysmem()Masahiro Yamada
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>
2016-07-01pinctrl: uniphier: avoid building unneeded pin-mux tables for SPLMasahiro Yamada
SPL does not use all of the devices, so we can save some memory footprint. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-07-01pinctrl: uniphier: support pin configuration for dedicated pinsMasahiro Yamada
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>
2016-07-01pinctrl: uniphier: allow to have pinctrl node under syscon nodeMasahiro Yamada
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>
2016-03-31pinctrl: uniphier: support per-pin input enable for new SoCsMasahiro Yamada
Upcoming new pinctrl drivers for PH1-LD11 and PH-LD20 support input signal gating for each pin. (While, existing ones only support it per pin-group.) This commit prepares the core part for that. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-03-31pinctrl: uniphier: introduce capability flagMasahiro Yamada
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>
2016-01-25bug.h: move BUILD_BUG_* defines to include/linux/bug.hMasahiro Yamada
BUILD_BUG_* macros have been defined in several headers. It would be nice to collect them in include/linux/bug.h like Linux. This commit is cherry-picking useful macros from include/linux/bug.h of Linux 4.4. I did not import BUILD_BUG_ON_MSG() because it would not work if it is used with include/common.h in U-Boot. I'd like to postpone it until the root cause (the "error()" macro in include/common.h causes the name conflict with "__attribute__((error()))") is fixed. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-09-23pinctrl: uniphier: add UniPhier pinctrl core supportMasahiro Yamada
The core support for the pinctrl drivers for all the UniPhier SoCs. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Simon Glass <sjg@chromium.org>