This patch updates device's probing, removal and irq handling in order to
register it as pinctrl device. Pin control data is matched by ACPI UID,
since it is passed along as driver data in acpi_device_id structure.
Signed-off-by: NCristina Ciocan <cristina.ciocan@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch updates the irq chip implementation in order
to interact with the pin control chip model: the chip
contains reference to SOC data and pin/group/community
information is retrieved through the SOC reference.
Signed-off-by: NCristina Ciocan <cristina.ciocan@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch updates the gpio chip implementation in order
to interact with the pin control model: the chip contains
reference to SOC data and pin/group/community information
is retrieved through the SOC reference.
Signed-off-by: NCristina Ciocan <cristina.ciocan@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add implementation for:
- pin control, group information retrieval: count, name and pins
- pin muxing:
  - function information (count, name and groups)
  - mux setting
  - gpio control (enable, disable, set direction)
- pin configuration:
  - pull disable
  - pull up/down and pull strength
  - debounce
  - any other option is treated as not supported.
Signed-off-by: NCristina Ciocan <cristina.ciocan@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to implement pin control for Baytrail, we need data
structures in which to store and pass along pin, group, function,
community and SOC data information.

Baytrail has 3 GPIO controllers. Add SCORE, NCORE and SUS
controller data:
- pins (for all controllers),
- pad map for pins (for all controllers; we need this since pads
  are not ordered),
- groups (for SCORE and SUS controllers),
- functions (for SCORE and SUS controllers),
- communities (for all controllers),
- soc specific data gathering all of the above and the ACPI UID
  (for all controllers)

This information is useful for pin control functionality.
NCORE data is lighter than the other two controllers' due to
lack of pin documentation in the public datasheet.

Datasheet:
http://www.intel.com/content/www/us/en/embedded/products/bay-trail/atom-e3800-family-datasheet.htmlSigned-off-by: NCristina Ciocan <cristina.ciocan@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinctrl-intel doesn't use anything from <linux/init.h>,
<linux/acpi.h>, <linux/gpio.h> or <linux/pm.h>, so it should not
include these header files.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

As we want gpio_chip .get() calls to be able to return negative
error codes and propagate to drivers, we need to go over all
drivers and make sure their return values are clamped to [0,1].
We do this by using the ret = !!(val) design pattern.
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This reverts commit c5cdcba3.

The calculation equation of PAD_OWN register offset is not
correct for Broxton, verified this fix will get right
offset for Broxton.
Signed-off-by: NQi Zheng <qi.zheng@intel.com>
Signed-off-by: NQipeng Zha <qipeng.zha@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The group size for registers PADCFGLOCK, HOSTSW_OWN, GPI_IS,
GPI_IE, are not 24 for Broxton, Add a parameter to allow
different platform to set correct value.
Signed-off-by: NQi Zheng <qi.zheng@intel.com>
Signed-off-by: NQipeng Zha <qipeng.zha@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The group size for registers PADCFGLOCK, HOSTSW_OWN, GPI_IS,
GPI_IE, are not 24 for Broxton, Add a parameter to allow
different platform to set correct value.
Signed-off-by: NQi Zheng <qi.zheng@intel.com>
Signed-off-by: NQipeng Zha <qipeng.zha@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.

This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:

@@
struct gpio_chip *var;
@@
-var->dev
+var->parent

and:

@@
struct gpio_chip var;
@@
-var.dev
+var.parent

and:

@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent

Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.

This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Alek Du <alek.du@intel.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This driver adds pinctrl/GPIO support for Intel Broxton. The GPIO
controller is based on the same hardware design that is already used in
Intel Sunrisepoint so we leverage the core driver here.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Reserved for ACPI actually means that in such case the GPIO hardware will
not update the interrupt status register (GPI_IS) even if the pin is
configured to trigger an interrupt. It will update GPI_GPE_STS instead and
does not trigger an interrupt.

Allow using such pins as GPIOs, only prevent their usage as interrupts.

We also rename function intel_pad_reserved_for_acpi() to be
intel_pad_acpi_mode() which reflects the actual meaning better.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

On Intel Broxton the GPIO hardware consists of several chips that all share
the parent interrupt. It is not possible to handle this by setting chained
handler for each chip (as they will overwrite each other).

To overcome this we need to request the interrupt using devm_request_irq()
and pass IRQF_SHARED with the flags.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When CONFIG_PM is not set we get following compilation warnings:

 warning: ‘byt_gpio_runtime_suspend’ defined but not used [-Wunused-function]
 warning: ‘byt_gpio_runtime_resume’ defined but not used [-Wunused-function]

Fix this by guarding byt_gpio_runtime_suspend()/byt_gpio_runtime_resume()
with #ifdef CONFIG_PM.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We get following warning when CONFIG_PM_SLEEP is not set

  warning: ‘intel_gpio_irq_init’ defined but not used [-Wunused-function]

Since the function is only called from intel_pinctrl_resume() move it
inside CONFIG_PM_SLEEP guard as well.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Replace all trivial request/free callbacks that do nothing but call into
pinctrl code with the generic versions.
Signed-off-by: NJonas Gorski <jogo@openwrt.org>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NEric Anholt <eric@anholt.net>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NAndrew Bresticker <abrestic@chromium.org>
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Acked-by: NMatthias Brugger <matthias.bgg@gmail.com>
Acked-by: NLee Jones <lee@kernel.org>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most interrupt flow handlers do not use the irq argument. Those few
which use it can retrieve the irq number from the irq descriptor.

Remove the argument.

Search and replace was done with coccinelle and some extra helper
scripts around it. Thanks to Julia for her help!
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Jiang Liu <jiang.liu@linux.intel.com>

When running -rt kernel and an interrupt happens on a GPIO line controlled by
Intel Cherryview/Braswell pinctrl driver we get:

 BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
 Preemption disabled at:[<ffffffff81092e9f>] cpu_startup_entry+0x17f/0x480

 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #16
  ...
 Call Trace:
  <IRQ>  [<ffffffff816283c6>] dump_stack+0x4a/0x61
  [<ffffffff81077e17>] ___might_sleep+0xe7/0x170
  [<ffffffff8162d6cf>] rt_spin_lock+0x1f/0x50
  [<ffffffff812e52ed>] chv_gpio_irq_ack+0x3d/0xa0
  [<ffffffff810a72f5>] handle_edge_irq+0x75/0x180
  [<ffffffff810a3457>] generic_handle_irq+0x27/0x40
  [<ffffffff812e57de>] chv_gpio_irq_handler+0x7e/0x110
  [<ffffffff810050aa>] handle_irq+0xaa/0x190
  ...

This is because desc->lock is raw_spinlock and is held when chv_gpio_irq_ack()
is called by the genirq core. chv_gpio_irq_ack() in turn takes pctrl->lock
which in -rt is an rt-mutex causing might_sleep() rightfully to complain about
sleeping function called from invalid context.

In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Intel Baytrail pinctrl driver implements irqchip callbacks which are
called with desc->lock raw_spinlock held. In mainline this is fine because
spinlock resolves to raw_spinlock. However, running the same code in -rt we
get:

 BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
 Preemption disabled at:[<ffffffff81092e9f>] cpu_startup_entry+0x17f/0x480

 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.5-rt5 #13
  ...
 Call Trace:
  <IRQ>  [<ffffffff816283c6>] dump_stack+0x4a/0x61
  [<ffffffff81077e17>] ___might_sleep+0xe7/0x170
  [<ffffffff8162d6cf>] rt_spin_lock+0x1f/0x50
  [<ffffffff812e3b88>] byt_gpio_clear_triggering+0x38/0x60
  [<ffffffff812e3bc1>] byt_irq_mask+0x11/0x20
  [<ffffffff810a7013>] handle_level_irq+0x83/0x150
  [<ffffffff810a3457>] generic_handle_irq+0x27/0x40
  [<ffffffff812e3a5f>] byt_gpio_irq_handler+0x7f/0xc0
  [<ffffffff810050aa>] handle_irq+0xaa/0x190
  ...

This is because in -rt spinlocks are preemptible so taking the driver
private spinlock in irqchip callbacks causes might_sleep() to trigger.

In order to keep -rt happy but at the same time make sure that register
accesses get serialized, convert the driver to use raw_spinlock instead.

Also shorten the critical section a bit in few places.
Suggested-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is a hardware issue in Intel Baytrail where concurrent GPIO register
access might result reads of 0xffffffff and writes might get dropped
completely.

Prevent this from happening by taking the serializing lock in all places
where it is possible that more than one thread might be accessing the
hardware concurrently.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The FSF address is already mentioned in the COPYING file. No need to
duplicate that information to individual files.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There is a hardware issue in Intel Braswell/Cherryview where concurrent
GPIO register access might results reads of 0xffffffff and writes might get
dropped.

Prevent this from happening by taking the serializing lock for all places
where it is possible that more than one thread might be accessing the
hardware concurrently.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we
already have a pointer to corresponding irq_desc.
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Use irq_set_handler_locked() as it avoids a redundant lookup of the
irq descriptor.

Search and replacement was done with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org

Use irq_set_handler_locked() as it avoids a redundant lookup of the
irq descriptor.

Search and replacement was done with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org

Use irq_set_handler_locked() as it avoids a redundant lookup of the
irq descriptor.

Search and replacement was done with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.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>

If a driver does not set interrupt triggering type when it calls
request_irq(), it means use the pin as the hardware/firmware has
configured it. There are some drivers doing this. One example is
drivers/input/serio/i8042.c that requests the interrupt like:

	error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
			    "i8042", i8042_platform_device);

It assumes the interrupt is already properly configured. This is true in
case of interrupts connected to the IO-APIC. However, some Intel
Braswell/Cherryview based machines use a GPIO here instead for the internal
keyboard controller.

This is a problem because even if the pin/interrupt is properly configured,
the irqchip ->irq_set_type() will never be called as the triggering flags
are 0. Because of that we do not have correct interrupt flow handler set
for the interrupt.

Fix this by adding a custom ->irq_startup() that checks if the interrupt
has no triggering type set and in that case read the type directly from the
hardware and install correct flow handler along with the mapping.
Reported-by: NJagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reported-by: NFreddy Paul <freddy.paul@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Intel Sunrisepoint-H is a desktop version of the PCH (Platform Controller
Hub). It has slightly different pin configuration compared to the LP
version. This patch adds support for Sunrisepoint-H to the existing
pinctrl-sunrisepoint.c driver.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This driver supports pinctrl/GPIO hardware found on Intel Sunrisepoint (a
Skylake PCH) providing users a pinctrl and GPIO interfaces (including GPIO
interrupts).

The driver is split into core and platform parts so that the same core
driver can be reused in other drivers for other Intel GPIO hardware that is
based on the same host controller design.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

From the comments of gpiod_direction_output(), need to set @value
as initial output, so update the lowlevel routine to make it work.

Signed-off-by: jason.cj.chen<jason.cj.chen@intel.com>
Signed-off-by: Nqipeng.zha <qipeng.zha@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The BIOS might reconfigure pins as it needs when S3 is entered. This might
cause drivers using the GPIOs to fail because the state was wrong or
interrupts stopped working.

Fix this by saving and restoring enough pin context over system sleep.
Reported-by: NHans Holmberg <hans.holmberg@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of handling everything in the driver's first level interrupt
handler, we can take advantage of already existing flow handlers that are
provided by the IRQ core.

This changes the functionality a bit also. Previously the driver looped
over pending interrupts in a single loop, restarting the loop if some
interrupt changed state. This caused problem with Lenovo Thinkpad 10
digitizer that it was not able to deassert the interrupt before the driver
disabled the interrupt for good (looplimit was exhausted).

Rework the interrupt handling logic a bit so that we provide proper mask,
ack and unmask operations in terms of Baytrail GPIO hardware and loop over
pending interrupts only once. If the interrupt remains asserted the first
level handler will be re-triggered automatically.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If the pin is already configured as GPIO and it has any of the triggering
flags set, we may get spurious interrupts depending on the state of the
pin.

Prevent this by clearing the triggering flags on such pins. However, if the
pin is also configured as "direct IRQ" we leave the flags as is. Otherwise
it will prevent interrupts that are routed directly to IO-APIC.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Zotac ZBOX PI320, a Baytrail based mini-PC, has power button connected to a
GPIO pin and it is exposed to the operating system as Windows 8 button
array. This is implemented in Linux as a driver using gpio_keys.

However, BIOS on this particula machine forgot to mux the pin to be a GPIO
instead of native function, which results following message to be seen on
the console:

 byt_gpio INT33FC:02: pin 16 cannot be used as GPIO.

This causes power button to not work as the driver was not able to request
the GPIO it needs.

So instead of completely preventing this we allow turning the pin as GPIO
but issue warning that something might be wrong.
Reported-by: NBenjamin Adler <benadler@gmx.net>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>