The rk3368 is the first ARM64 soc from Rockchip, but seems to share most
peripherals with the ARM32 soc, including the pinctrl functionality.
The only notable difference is - as with every Rockchip soc - that the
offsets in the General Register Files moved around and a split of the pmu
section of the rk3288 into pmu and pmugrf (pmu general register files)
sections. The pinctrl driver of course only needs the pmugrf registers
for controlling the pin settings.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The upcoming support for the RK3368 ARM64 SoC also supports perpin
drive strength settings (at different register positions), so generalize
the register and offset calculation to easily support this one too.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus 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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NPatrice Chotard <patrice.chotard@st.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NLee Jones <lee@kernel.org>
Acked-by: NSören Brinkmann <soren.brinkmann@xilinx.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NRay Jui <rjui@broadcom.com>
Acked-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: NHongzhou Yang <hongzhou.yang@mediatek.com>
Acked-by: NWei Chen <Wei.Chen@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Rockchip GPIO interrupt controller totally throws away all status
about an interrupt when you "disable" the interrupt.  That has
unfortunate consequences in the following situation:

1. An edge-triggered interrupt is enabled and should wake the system.
2. System suspend happens: interrupt is disabled and marked for wake.
3. rockchip_irq_suspend() reenables the interrupt so we can wake.
4. Interrupt happens when asleep.
5. rockchip_irq_resume() redisables the interrupt.
6. Disabling the interrupt throws away all status about it.
7. Normal system resume happens and we enable the interrupt again,
   since we threw away status about the interrupt we don't know it
   fired while suspended.  Even worse: if we need both edges of the
   interrupt the logic to swap edges never runs.

Note: even if we somehow can post the status about wakeup interrupts
in rockchip_irq_resume() we would still have a window of losing any
edges that came in while interrupts were disabled.

If we use mask only then we don't need to worry.  The GPIO Interrupt
controller keeps track of pending interrupts that are enabled and just
masked.

There was no real strong reason to support the enable/disable
functionality (other than that it seemed right), so let's go back to
just supporting mask/unmask but actually map it to the real
mask/unmask.  This ends up with slightly different (and more correct)
behavior than before (f2dd028c pinctrl: rockchip: Fix
enable/disable/mask/unmask).
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

I was seeing cases where I was losing interrupts when inserting and
removing SD cards.  Sometimes the card would get "stuck" in the
inserted state.

I believe that the problem was related to the code to handle the case
where we needed both rising and falling edges.  This code would
disable the interrupt as the polarity was switched.  If an interrupt
came at the wrong time it could be lost.

We'll match what the gpio-dwapb.c driver does upstream and change the
interrupt polarity without disabling things.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus 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: NSoren Brinkmann <soren.brinkmann@xilinx.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Rockchip pinctrl driver was only implementing the "mask" and
"unmask" operations though the hardware actually has two distinct
things: enable/disable and mask/unmask.  It was implementing the
"mask" operations as a hardware enable/disable and always leaving all
interrupts unmasked.

I believe that the old system had some downsides, specifically:
- (Untested) if an interrupt went off while interrupts were "masked"
  it would be lost.  Now it will be kept track of.
- If someone wanted to change an interrupt back into a GPIO (is such a
  thing sensible?) by calling irq_disable() it wouldn't actually take
  effect.  That's because Linux does some extra optimizations when
  there's no true "disable" function: it does a lazy mask.

Let's actually implement enable/disable/mask/unmask properly.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The rockchip pinctrl driver was using irq_gc_set_wake() as its
implementation of irq_set_wake() but was totally ignoring everything
that irq_gc_set_wake() did (which is to upkeep gc->wake_active).

Let's fix that by setting gc->wake_active as GPIO_INTEN at suspend
time and restoring GPIO_INTEN at resume time.

NOTE a few quirks when thinking about this patch:
- Rockchip pinctrl hardware supports both "disable/enable" and
  "mask/unmask".  Right now we only use "disable/enable" and present
  those to Linux as "mask/unmask".  This should be OK because
  enable/disable is optional and Linux will implement it in terms of
  mask/unmask.  At the moment we always tell hardware all interrupts
  are unmasked (the boot default).
- At suspend time Linux tries to call "disable" on all interrupts and
  also enables wakeup on all wakeup interrupts.  One would think that
  since "disable" is implemented as "mask" when "disable" isn't
  provided and that since we were ignoring gc->wake_active that
  nothing would have woken us up.  That's not the case since Linux
  "optimizes" things and just leaves interrutps unmasked, assuming it
  could mask them later when they go off.  That meant that at suspend
  time all interrupts were actually being left enabled.

With this patch random non-wakeup interrupts no longer wake the system
up.  Wakeup interrupts still wake the system up.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Save and restore the gpio6_c6 pinmux setting, since Maskrom of RK3288
would modify it to sdmmc0_det, so it need to be restored to the correct
setting after resume from Maskrom.
Signed-off-by: NChris Zhong <zyw@rock-chips.com>
Tested-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

support suspend/resume of pinctrl, it allows handling sleep mode
for hogged pins in pinctrl
Signed-off-by: NChris Zhong <zyw@rock-chips.com>
Tested-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

There were a few instances where the rockchip pinctrl driver would do
read-modify-write with no spinlock.  Add a spinlock for these cases.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Just like in (529301c1 pinctrl: samsung: Parse pin groups before
calling pinctrl_register()), Rockchip also needs to parse pin groups
earlier to make hogs work.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NChris Zhong <zyw@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The Rockchip pinctrl driver was calling
rockchip_gpio_direction_output() in the pin_config_set() callback.
This was just a shortcut for:
* rockchip_gpio_set()
* pinctrl_gpio_direction_output()

Unfortunately it's not so good to call pinctrl_gpio_direction_output()
from pin_config_set().  Specifically when initting hogs you'll get an
error.

Let's refactor a little so we can call
_rockchip_pmx_gpio_set_direction() directly.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NChris Zhong <zyw@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

The rockchip pinctrl driver uses irq_gc_set_wake() but doesn't setup
the .wake_enabled member.  That means that we can never actually use a
pin for wakeup.  When "irq_set_irq_wake()" tries to call through it
will always get a failure from set_irq_wake_real() and will then set
wake_depth to 0.  Assuming you can resume you'll later get an error
message about "Unbalanced IRQ x wake disable".
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NChris Zhong <zyw@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

commit 2243a87d
"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: NStephen Warren <swarren@nvidia.com>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: NFan Wu <fwu@marvell.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

On rk3288, for gpio bank 0, the registers which configure pull-up,
iomux, and drive strength don't implement the enable bits in the upper
half of the register, unlike the other gpio configuration registers,
and so the kernel must perform a read-modify-write of the register to
update a particular gpio in that bank.

The current code is actually clobbering the contents of the register,
so this fixes it by using regmap_update_bits and masking out only the
bits which require updating.  In the case of bank0 on rk3288 the upper
enable bits will just get ignored, and the other configurations won't
get clobbered.
Signed-off-by: NSonny Rao <sonnyrao@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The rk3288 is the first Rockchip soc handling the drive strength on a per-pin
basis, while the older ones can set the drive-strength only for specific
pin-groups. Therefore limit setting the drive-strength to this soc for now.
Signed-off-by: NHeiko Stübner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

An upcoming pinctrl function of the rk3288 differs again from everything else,
so we'll need a separate type for it.
Signed-off-by: NHeiko Stübner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The rockchip pinctrl driver implements the generic pinconfig, therefore
also state this, so that the default pinconf dump functions work.
Signed-off-by: NHeiko Stübner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: Nabdoulaye berthe <berthe.ab@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pin-controller of the new RK3288 contains all the quirks just added in
the previous patches.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

On the upcoming RK3288 SoC contain some unrouted pins in their banks. So while
for example pin8 of bank5 stays pin8 with all its settings (register offset etc),
pins 0 to 7 are not routed outside the SoC at all.
Therefore add a flag to mark these unrouted iomuxes to prevent people from using
them.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The upcoming rk3288 moves some iomux settings to the pmu register space.
Therefore add a flag for this and adapt the mux functions accordingly.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In the upcoming rk3288 SoC some iomux settings are 4bit wide instead of
the regular 2bit. Therefore add a flag to mark iomuxes as such and adapt
the mux-access as well as the offset calculation accordingly.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

An upcoming SoC introduces an interesting quirk to iomux handling making the
calculation of the iomux register-offset harder. To keep the complexity down
when getting/setting the mux, precalculate the actual register offset at
probe-time.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Upcoming Rockchip SoCs have additional quirks to handle. Currently they would
be handled by giving the bank a special compatible property. But the nature
of the new quirks would require a lot of them. Also as we want to move to the
separate dw_gpio driver in the future, these bank-definitions should be
extended at all.

Describing the bank quirks this way also enables us to deprecate the special
bank compatible string for bank0 on rk3188 and simplify the handling code.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus 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: NFan Wu <fwu@marvell.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NPatrice Chotard <patrice.chotard@st.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This allows the basic registers of the general register files to be supplied
by a syscon instead of being mapped locally.

The GRF registers contain a lot more than pinctrl functions like dma, usb-phy
and general soc control and status registers, intermixed with the iomux, pull
and drive-strength registers.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When the pmu registers are supplied through a syscon regmap we do not need
to map the registers ourself.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently the pmu registers containing pin pull settings on the rk3188 are mapped
locally when bank0 is instantiated. Add an alternative that can resolve the pmu
from a syscon phandle.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Convert rockchip_get_bank_data to use the struct rockchip_pinctrl because
later on we need to check a value from it when registering the gpio banks.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This allows us to use syscons in the future.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Deprecate secondary register area for rk3188 pulls. Instead use big enough
initial mapping of grf registers to catch all.

The now deprecated register is still supported though.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In some cases it is nice to be able to simply control a gpio output
via the PIN_CONFIG_OUTPUT option without having a driver control it.
Thus add support for it to the rockchip pinctrl driver.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Till now pinconf_get only set the argument value into the config parameter
effectively removing the actual config param value. As other pinctrl drivers
do, it might be nicer to keep the config param intact.
Therefore construct a real pinconfig value from param and arg in pinconf_get
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The first half of pinbank 0 only has one muxing function (as gpios) and
does not have a special mux-register.

Therefore ensure that no other mux function can be selected and also do not
write to a non-existent register.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In a following change, rockchip_set_mux gets the possibility to fail.
Therefore add a return value to it and honor error codes in functions
using rockchip_set_mux.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The correct value of .mux_offset for rk3188 seems to be 0x60
instead of 0x68.

Heiko adds:

GPIO0 only has the second two IOMUX registers:
- GRF_GPIO0C_IOMUX at 0x68
- GRF_GPIO0D_IOMUX at 0x6c
which I guess is where my mistake comes from.

It looks like there does no iomux register exist at all
for the first 16 pins.

In any case, the current number is wrong, and the 0x60
offset is the correct one, but I guess we need to
determine what the affected pins do - do they always have a
gpio mux or such?
Signed-off-by: NBeniamino Galvani <b.galvani@gmail.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We need to unlock here before returning -EINVAL.

Fixes: 6ca5274d ('pinctrl: rockchip: add rk3188 specifics')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>