litmus-rt.git/drivers/pinctrl/intel, branch test

pinctrl: cherryview: Read triggering type from HW if not set when requested

2015-05-12T11:54:32+00:00

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: Jagadish Krishnamoorthy 
Reported-by: Freddy Paul 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

Merge tag 'pinctrl-v4.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2015-04-15T00:58:15+00:00

Pull pincontrol updates from Linus Walleij:
 "This is the bulk of pin control changes for the v4.1 development
  cycle.  Nothing really exciting this time: we basically added a few
  new drivers and subdrivers and stabilized them in linux-next.  Some
  cleanups too.  With sunrisepoint Intel has a real fine fully featured
  pin control driver for contemporary hardware, and the AMD driver is
  also for large deployments.  Most of the others are ARM devices.

  New drivers:
    - Intel Sunrisepoint
    - AMD KERNCZ GPIO
    - Broadcom Cygnus IOMUX

  New subdrivers:
    - Marvell MVEBU Armada 39x SoCs
    - Samsung Exynos 5433
    - nVidia Tegra 210
    - Mediatek MT8135
    - Mediatek MT8173
    - AMLogic Meson8b
    - Qualcomm PM8916

  On top of this cleanups and development history for the above drivers
  as issues were fixed after merging"

* tag 'pinctrl-v4.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (71 commits)
  pinctrl: sirf: move sgpio lock into state container
  pinctrl: Add support for PM8916 GPIO's and MPP's
  pinctrl: bcm2835: Fix support for threaded level triggered IRQs
  sh-pfc: r8a7790: add EtherAVB pin groups
  pinctrl: Document "function" + "pins" pinmux binding
  pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support
  pinctrl: fsl: imx: Check for 0 config register
  pinctrl: Add support for Meson8b
  documentation: Extend pinctrl docs for Meson8b
  pinctrl: Cleanup Meson8 driver
  Fix inconsistent spinlock of AMD GPIO driver which can be recognized by static analysis tool smatch. Declare constant Variables with Sparse's suggestion.
  pinctrl: at91: convert __raw to endian agnostic IO
  pinctrl: constify of_device_id array
  pinctrl: pinconf-generic: add dt node names to error messages
  pinctrl: pinconf-generic: scan also referenced phandle node
  pinctrl: mvebu: add suspend/resume support to Armada XP pinctrl driver
  pinctrl: st: Display pin's function when printing pinctrl debug information
  pinctrl: st: Show correct pin direction also in GPIO mode
  pinctrl: st: Supply a GPIO get_direction() call-back
  pinctrl: st: Move st_get_pio_control() further up the source file
  ...

pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support

2015-04-07T13:15:23+00:00

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: Mathias Nyman 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: update direction_output function of cherryview driver

2015-03-10T08:02:23+00:00

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
Signed-off-by: qipeng.zha 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: baytrail: Save pin context over system sleep

2015-03-06T11:25:07+00:00

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: Hans Holmberg 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: baytrail: Rework interrupt handling

2015-03-06T11:22:41+00:00

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: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: baytrail: Clear interrupt triggering from pins that are in GPIO mode

2015-03-06T11:21:09+00:00

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: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: baytrail: Relax GPIO request rules

2015-03-06T11:19:51+00:00

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: Benjamin Adler 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: cherryview: Configure HiZ pins to be input when requested as GPIOs

2015-02-04T08:59:26+00:00

If the pin is in HiZ mode when it is requested as GPIO its value cannot be
read (it always returns 0). In order to cope with the Linux GPIO subsystem
where we do not have such state at all, turn the pin to be input instead.

Reported-by: Jerome Blin 
Signed-off-by: Mika Westerberg 
Signed-off-by: Linus Walleij

pinctrl: intel: drop owner assignment from platform_drivers

2015-01-10T21:47:23+00:00

This platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij