On modern Renesas SoCs, all PFC registers are 32-bit, and all callers of
sh_pfc_{read,write}_reg() already operate on 32-bit registers only.
Hence make the 32-bit width implicit, and rename the functions to
sh_pfc_{read,write}() to shorten lines.
All accesses to 8-bit or 16-bit registers are still done using
sh_pfc_{read,write}_raw_reg().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Propagate errors on group config, now r8a7740-armadillo800eva.dts is
fixed,
- Add MSIOF and USB2.0 pin groups on R-Car H3 ES2.0,
- Add USB2.0 and USB3.0 pin groups on R-Car M3-W,
- Add a missing MMC pin group on R-Car M2-W and RZ/G1M,
- Add initial support for R-Car D3,
- Small fixes and cleanups.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZlWFUAAoJEEgEtLw/Ve77evIP/RIdkXo3MM9fHmbDUbpPFHH/
AY/8hwBh0r2ayfxoIzsj4EuRlOLgebrusa0VEFSp6kMOhuN2EB9wMMjnGG96I5Ld
8LoWEqddG9btxvWIRjaC7j1VBz3clU7RLb6nIWzY9sW0L8xJ7Dk6P+gudRQqu9VU
RRCdj8RCx3tFtWRgfJOXnlHSQo1H/okDa7V2H8NddVDLHNMb5400kUaJnFG9CpMl
YNqrU8yVSs3vYCZxvNxchL0IcxSNuhwkMA2OHw8iNxuTZuDvNpIiHDfCNPmmqnlk
4FFFNEKf6No1Y/726ba3tKSIMUTCS8FXel+nRxea9vTpx5smTfy3BH5ngcD9JJHA
aeuhlGKBtgyMhJ839SOfTbFwosvdSjvf41NtaKDtLD8AwB2MxI0jfCaa4+M3McVv
gSgF0lQczg3PHPv6s1DnJGmOGCbwvgxp61jYNzrKziZXfKtTCZd8PFY9v+/Tgr0H
5+6Z17LR5/eNszxZVAV7V8WMTa6rME7rooyEG4f+ZnU09S7fDohWEkMDTRBY5Kna
9X9pHiDytsfRGhMwewr2HYabu3RoLLLBCJGXg4L9DuMeN0+tLLlxNm+jkaVM8gyG
gC4SdTOucyF5z3K7o7TrAdBktMPJZjY9LhGtazS6dtG1gvFhpZoky5lJJr9CQk05
0EooaisR3ONv/LRAw6AH
=xgLM
-----END PGP SIGNATURE-----
Merge tag 'sh-pfc-for-v4.14-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: sh-pfc: Updates for v4.14
- Propagate errors on group config, now r8a7740-armadillo800eva.dts is
fixed,
- Add MSIOF and USB2.0 pin groups on R-Car H3 ES2.0,
- Add USB2.0 and USB3.0 pin groups on R-Car M3-W,
- Add a missing MMC pin group on R-Car M2-W and RZ/G1M,
- Add initial support for R-Car D3,
- Small fixes and cleanups.
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee@kernel.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Barry Song <baohua@kernel.org>
Cc: linux-gpio@vger.kernel.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: kernel@stlinux.com
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On group configuration, bail out if setting one of the individual pins
fails. We don't need to roll-back, the pinctrl core will do this for us.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Recent pinctrl changes to allow dynamic allocation of pins exposed one
more issue with the pinctrl pins claimed early by the controller itself.
This caused a regression for IMX6 pinctrl hogs.
Before enabling the pin controller driver we need to wait until it has
been properly initialized, then claim the hogs, and only then enable it.
To fix the regression, split the code into pinctrl_claim_hogs() and
pinctrl_enable(). And then let's require that pinctrl_enable() is always
called by the pin controller driver when ready after calling
pinctrl_register_and_init().
Depends-on: 950b0d91dc ("pinctrl: core: Fix regression caused by delayed
work for hogs")
Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Fixes: e566fc11ea ("pinctrl: imx: use generic pinctrl helpers for
managing groups")
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Mika Penttilä <mika.penttila@nextfour.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Gary Bisson <gary.bisson@boundarydevices.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
regression at least with sh-pfc that is also a GPIO controller as
noted by Geert Uytterhoeven <geert@linux-m68k.org>.
As the original pinctrl_register() has issues calling pin controller
driver functions early before the controller has finished registering,
we can't just revert commit df61b366af26. That would break the drivers
using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
So let's fix the issue with the following steps as a single patch:
1. Revert the late_init parts of commit df61b366af26.
The late_init clearly won't work and we have to just give up
on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
GENERIC_PINMUX_FUNCTIONS.
2. Split pinctrl_register() into two parts
By splitting pinctrl_register() into pinctrl_init_controller()
and pinctrl_create_and_start() we have better control over when
it's safe to call pinctrl_create().
3. Introduce a new pinctrl_register_and_init() function
As suggested by Linus Walleij <linus.walleij@linaro.org>, we
can just introduce a new function for the controllers that need
pinctrl_create() called later.
4. Convert the four known problem cases to use new function
Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
to use the new function to fix the issues. The rest of the drivers
can be converted later. Let's also update Documentation/pinctrl.txt
accordingly because of the known issues with pinctrl_register().
Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output
when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if
the operation get_bias() is implemented but the pin is not handled by
the get_bias() implementation. In that case the output will state that
"input bias disabled" indicating that this pin has bias control
support.
Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either
supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also
solves the issue where SoC specific implementations print error messages
if their particular implementation of {set,get}_bias() is called with a
pin it does not know about.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
The pinconf-generic code expects configurations with arguments to be
returned in a packed format in order to be displayed properly by
pinconf_generic_dump_one().
Reading /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins on
r8a7795/salvator-x now shows:
pin 101 (GP_3_5): output drive strength (9 mA), pin power source (3300 selector)
Instead of:
pin 101 (GP_3_5): output drive strength (0 mA), pin power source (0 selector)
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
All known hardware being able to switch voltages has the same POCCTRL
register. So, factor out the common code to the core and keep only
the pin-to-bit mapping SoC specific. Convert the only user, r8a7790.
In case POCCTRL should ever get more complex (more voltages to select?),
we should probably switch over to a describing array like drive strength
does currently.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add support for the drive-strengh pin configuration using the generic
pinconf DT bindings.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
for_each_child_of_node performs an of_node_get on each iteration, so a
goto out of the loop requires an of_node_put.
A simplified version of the semantic patch that fixes this problem is as
follows (http://coccinelle.lip6.fr):
// <smpl>
@@
local idexpression n;
expression e,e1;
identifier l;
@@
for_each_child_of_node(e1,n) {
...
(
of_node_put(n);
|
e = n
|
return n;
|
+ of_node_put(n);
? goto l;
)
...
}
l: ... when != n
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The pfc in the R8A7790 (and probably others in the R-Car gen 2 family)
supports switching SDHI signals between 3.3V and 1.8V nominal voltage,
and the SD driver should do that when switching to and from UHS modes.
Add a flag for pins that have configurable I/O voltage and SoC
operations to get and set the nominal voltage. Implement the pinconf
power-source parameter using these operations.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The "function", "pins" and "groups" pinmux and pinctrl properties have
been standardized. Support them in addition to the custom "renesas,*"
properties. New-style and old-style properties can't be mixed in DT.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently, pinctrl_register() just returns NULL on error, so the
callers can not know the exact reason of the failure.
Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some
-ENOMEM on error of pinctrl_register(), although the error code
might be different from the real cause of the error.
This commit reworks pinctrl_register() to return the appropriate
error code and modifies all of the pinctrl drivers to use IS_ERR()
for the error checking and PTR_ERR() for getting the error code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Ray Jui <rjui@broadcom.com>
Acked-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Acked-by: Wei Chen <Wei.Chen@csr.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Additionally to the generic DT parameters, allow drivers to provide
driver-specific DT parameters to be used with the generic parser
infrastructure.
To achieve this 'struct pinctrl_desc' is extended to pass custom pinconf
option to the core. In order to pass this kind of information, the
related data structures - 'struct pinconf_generic_dt_params',
'pin_config_item' - are moved from pinconf internals to the
pinconf-generic header.
Additionally pinconfg-generic is refactored to not only iterate over the
generic pinconf parameters but also take the parameters into account
that are provided through the driver's 'struct pinctrl_desc'.
In particular 'pinconf_generic_parse_dt_config()' and
'pinconf_generic_dump' helpers are split into two parts each. In order
to have a more generic helper that can be used to process the generic
parameters as well as the driver-specific ones.
v2:
- fix typo
- add missing documentation for @conf_items member in struct
- rebase to pinctrl/devel: conflict in abx500
- rename _pinconf_generic_dump() to pinconf_generic_dump_one()
- removed '_' from _parse_dt_cfg()
- removed BUG_ONs, error condition is handled in if statements
- removed pinconf_generic_dump_group() & pinconf_generic_dump_pin
helpers
- fixed up corresponding call sites
- renamed pinconf_generic_dump() to pinconf_generic_dump_pins()
- added kernel-doc to pinconf_generic_dump_pins()
- add kernel-doc
- more verbose commit message
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
commit 2243a87d90
"pinctrl: avoid duplicated calling enable_pinmux_setting for a pin"
removed the .disable callback from the struct pinmux_ops,
making the .enable() callback the only remaining callback.
However .enable() is a bad name as it seems to imply that a
muxing can also be disabled. Rename the callback to .set_mux()
and also take this opportunity to clean out any remaining
mentions of .disable() from the documentation.
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: Fan Wu <fwu@marvell.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
What the patch does:
1. Call pinmux_disable_setting ahead of pinmux_enable_setting
each time pinctrl_select_state is called
2. Remove the HW disable operation in pinmux_disable_setting function.
3. Remove the disable ops in struct pinmux_ops
4. Remove all the disable ops users in current code base.
Notes:
1. Great thanks for the suggestion from Linus, Tony Lindgren and
Stephen Warren and Everyone that shared comments on this patch.
2. The patch also includes comment fixes from Stephen Warren.
The reason why we do this:
1. To avoid duplicated calling of the enable_setting operation
without disabling operation inbetween which will let the pin
descriptor desc->mux_usecount increase monotonously.
2. The HW pin disable operation is not useful for any of the
existing platforms.
And this can be used to avoid the HW glitch after using the
item #1 modification.
In the following case, the issue can be reproduced:
1. There is a driver that need to switch pin state dynamically,
e.g. between "sleep" and "default" state
2. The pin setting configuration in a DTS node may be like this:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&a_grp_setting &c_grp_setting>;
pinctrl-1 = <&b_grp_setting &c_grp_setting>;
}
The "c_grp_setting" config node is totally identical, maybe like
following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = <GPIO48 AF6>;
}
3. When switching the pin state in the following official pinctrl
sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1. The switch is completed as expected, that is: the device's
pin configuration is changed according to the description in the
"wanted_state" group setting
2. The "desc->mux_usecount" of the corresponding pins in "c_group"
is increased without being decreased, because the "desc" is for
each physical pin while the setting is for each setting node
in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead
of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount
will keep increasing without any chance to be decreased.
According to the comments in the original code, only the setting,
in old state but not in new state, will be "disabled" (calling
pinmux_disable_setting), which is correct logic but not intact. We
still need consider case that the setting is in both old state
and new state. We can do this in the following two ways:
1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin
setting" repeatedly
2. "Disable"(calling pinmux_disable_setting) the "same pin setting",
actually two setting instances, ahead of enabling them.
Analysis:
1. The solution #2 is better because it can avoid too much
iteration.
2. If we disable all of the settings in the old state and one of
the setting(s) exist in the new state, the pins mux function
change may happen when some SoC vendors defined the
"pinctrl-single,function-off"
in their DTS file.
old_setting => disabled_setting => new_setting.
3. In the pinmux framework, when a pin state is switched, the
setting in the old state should be marked as "disabled".
Conclusion:
1. To Remove the HW disabling operation to above the glitch mentioned
above.
2. Handle the issue mentioned above by disabling all of the settings
in old state and then enable the all of the settings in new state.
Signed-off-by: Fan Wu <fwu@marvell.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When setting pin configuration in the pinctrl framework, pin_config_set() or
pin_config_group_set() is called in a loop to set one configuration at a time
for the specified pin or group.
This patch 1) removes the loop and 2) changes the API to pass the whole pin
config array to the driver. It is now up to the driver to loop through the
configs. This allows the driver to potentially combine configs and reduce the
number of writes to pin config registers.
All c files changed have been build-tested to verify the change compiles and
that the corresponding .o is successfully generated.
Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Christian Daudt <csd@broadcom.com>
Reviewed-by: Matt Porter <matt.porter@linaro.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Remove the manually specified ranges from PFC SoC data and compute the
ranges automatically. This prevents ranges from being out-of-sync with
pins definitions.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
The field contains the number of pins with an associated GPIO port. This
is currently equal to the total number of pins but will be modified when
adding support for pins without a GPIO port. Rename the field
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Fix a compilation error caused by pinconf_generic_parse_dt_config() not
being defined on !CONFIG_OF platforms by guarding the whole DT node
parsing code with #ifdef CONFIG_OF.
Defining a pinconf_generic_parse_dt_config() on !CONFIG_OF would have
been possible as well, but would have resulted in a larger code size on
!CONFIG_OF platforms (such as arch/sh).
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Support device instantiation through the device tree. The compatible
property is used to select the SoC pinmux information.
Set the gpio_chip device field to the PFC device to enable automatic
GPIO OF support.
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When a GPIO is handled by a separate driver the pinmux
gpio_set_direction() handler won't be called. The pin mux type then need
to be configured to GPIO at request time.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
When setting a pin direction verify that the requested direction is
supported, and return an error if it isn't.
This requires pin configuration information to be supplied by SoC data.
The check is a no-op if the information is not supplied.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Set pin configuration type to
- PINMUX_TYPE_NONE at initialization time and when disabling a function
or freeing a GPIO
- PINMUX_TYPE_FUNCTION when enabling a function
- PINMUX_TYPE_INPUT or PINMUX_TYPE_OUTPUT when setting the GPIO
direction
Verify that the type is PINMUX_TYPE_NONE when enabling a function or
requesting a GPIO and return -EBUSY if it isn't.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The sh_pfc_reconfig_pin() is only called from a single location. Merge
it into its call site to make the code easier to follow.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The existing PFC pinconf implementation, tied to the PFC-specific pin
types, isn't used by drivers or boards. Replace it with the generic
pinconf types to implement bias (pull-up/down) setup. Other pin
configuration options can be implemented later if needed.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
None of the SoC data need to be modified. Constify it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The purpose of the dry-run is to ensure that a pin about to be
configured isn't in use. However, the current implementation is a no-op.
This proves that the dry-run isn't essential. Remove it.
Freeing configuration then becomes a no-op as well. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The sh_pfc_pin structure supplied in SoC data contains information about
pin configuration and name. It's abused to store GPIO data registers
information and pin config type. Move those fields out of the
pinmux_data_reg structure into the new sh_pfc_gpio_pin and
sh_pfc_pin_config structures.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
In case of error, the function pinctrl_register() returns NULL not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The sh-pfc driver exposes one fake group and function per GPIO pin. As
the pinctrl and pinmux APIs are not used by any SuperH and SH Mobile
board or driver, drop the fake groups and functions and replace them by
a real pinctrl and pinmux implementation.
Groups and functions must now be explicitly provided by PFC SoC-specific
data.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The PFC driver assumes that the value of the GPIO_PORTxxx enumeration
names are equal to the port number. This isn't true when the port number
space is sparse, as with the SH73A0.
Fix the issue by adding support for pin numbers ranges specified through
SoC data. When no range is specified the driver considers that the PFC
implements a single contiguous range for all pins.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Adding a GPIO range to a pinctrl device logically belongs to the GPIO
driver. Switch to the right API.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
This prepares support for sparse pin numbering. The function currently
just performs and indexed lookup in the pins array.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The PFC core exposes a sh_pfc_config_gpio() function that configures
pinmuxing for a given GPIO (either a real GPIO or a function GPIO).
Handling of real and function GPIOs belong to the GPIO layer, move the
GPIO number to mark translation to the caller and rename the function to
sh_pfc_config_mux().
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
And drop the pinmux_flag_t typedef.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Split the GPIOs table into a pins table for real GPIOs and a functions
table for function GPIOs.
Only register pins with the pinctrl core. The function GPIOs remain
accessible as GPIOs.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
As a step towards GPIO function removal, shorten the GPIO range
registered with the pinctrl core. Function GPIOs are now handled in the
GPIO handlers directly instead of going through the pinctrl API.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
All function GPIO entries are initialized with the GPIO_FN macro that
expands to the PINMUX_GPIO macro, used to initialize real GPIOs. Create
a PINMUX_GPIO_FN macro that duplicates PINMUX_GPIO and sets flags to
PINMUX_TYPE_FUNCTION and use it in GPIO_FN, and make PINMUX_GPIO set
flags to PINMUX_TYPE_GPIO.
This removes the need to initialize GPIO flags at runtime and thus
simplifies the code, preparing for the GPIO and functions split.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The SoC information first_gpio field is always equal to 0, and the
last_gpio field is the index of the last entry in the pinmux_gpios
array. Replace the first_gpio and last_gpio fields by a nr_gpios field,
and initialize it to ARRAY_SIZE(pinmux_gpios).
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The sh_pfc_map_gpios() function is only called at initialization time
when no other task can access the sh_pfc fields. Don't protect the
operation with a spinlock.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The spinlock is used to protect data that is only accessed sequentially
during initialization. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The pinctrl_desc and pinctrl_gpio_range structures registered with the
pinctrl core are per-device instances. Move them to the dynamically
allocated sh_pfc_pinctrl structure and initialize them at runtime.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
