Linus Walleij [Mon, 13 Nov 2017 10:04:27 +0000 (11:04 +0100)]
pinctrl: Add some depends on HAS_IOMEM
Some compilation fallout from UM Linux (which does not have
IOMEM) makes it necessary to depend on HAS_IOMEM for drivers
that doesn't have other factors restricting their selection.
Cc: Phil Reid <preid@electromag.com.au> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Reported-by: R. Daneel Olivaw <kbuild-all@01.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
drivers/pinctrl/samsung/pinctrl-samsung.c: In function 'samsung_gpiolib_register':
drivers/pinctrl/samsung/pinctrl-samsung.c:936:5: error: 'struct gpio_chip' has no member named 'of_node'
This configuration is now possible since we can now select the
PINCTRL subsystem on S3C24xx machines other than the device tree
based ones.
Fixes: d219b924611a ("pinctrl: change Kconfig PINCTRL variable to a menuconfig") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Thierry Reding [Tue, 7 Nov 2017 18:15:59 +0000 (19:15 +0100)]
gpio: Automatically add lockdep keys
In order to avoid lockdep boilerplate in individual drivers, turn the
gpiochip_add_data() function into a macro that creates a unique class
key for each driver.
Note that this has the slight disadvantage of adding a key for each
driver registered with the system. However, these keys are 8 bytes in
size, which is negligible and a small price to pay for generic
infrastructure.
Thierry Reding [Tue, 7 Nov 2017 18:15:58 +0000 (19:15 +0100)]
gpio: Introduce struct gpio_irq_chip.first
Some GPIO chips cannot support sparse IRQ numbering and therefore need
to manually allocate their interrupt descriptors statically. For these
cases, a driver can pass the first allocated IRQ via the struct
gpio_irq_chip's "first" field and thereby cause the IRQ domain to map
all IRQs during initialization.
Thierry Reding [Tue, 7 Nov 2017 18:15:57 +0000 (19:15 +0100)]
gpio: Disambiguate struct gpio_irq_chip.nested
The nested field in struct gpio_irq_chip currently has two meanings. On
one hand it marks an IRQ chip as being nested (as opposed to chained),
while on the other hand it also means that an IRQ chip uses nested
thread handlers.
However, nested IRQ chips can already be identified by the fact that
they don't pass a parent handler (the driver would instead already have
installed a nested handler using request_irq()).
Therefore, the only use for the nested attribute is to inform gpiolib
that an IRQ chip uses nested thread handlers (as opposed to regular,
non-threaded handlers). To clarify its purpose, rename the field to
"threaded".
Thierry Reding [Tue, 7 Nov 2017 18:15:56 +0000 (19:15 +0100)]
gpio: Add Tegra186 support
Tegra186 has two GPIO controllers that are largely register compatible
between one another but are completely different from the controller
found on earlier generations.
Thierry Reding [Tue, 7 Nov 2017 18:15:54 +0000 (19:15 +0100)]
gpio: Implement tighter IRQ chip integration
Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.
Thierry Reding [Tue, 7 Nov 2017 18:15:45 +0000 (19:15 +0100)]
gpio: Introduce struct gpio_irq_chip
This new structure will be used to group all fields related to interrupt
handling in a GPIO chip. Doing so will properly namespace these fields
and make it easier to distinguish which fields are used for IRQ support.
Linus Walleij [Mon, 6 Nov 2017 20:27:34 +0000 (21:27 +0100)]
pinctrl: gemini: Fix GMAC groups
The GMII groups need to be split across GMAC0 and GMAC1 since
GMAC0 is always available but GMAC1 masks GPIO2 lines 0-7
so we might want just one interface out.
Colin Ian King [Tue, 31 Oct 2017 11:20:51 +0000 (11:20 +0000)]
pinctrl: ti-iodelay: remove redundant unused variable dev
The pointer dev is being assigned but is never used, hence it is
redundant and can be removed. Cleans up clang warnings:
drivers/pinctrl/ti/pinctrl-ti-iodelay.c:582:2: warning: Value stored
to 'dev' is never read
drivers/pinctrl/ti/pinctrl-ti-iodelay.c:701:2: warning: Value stored
to 'dev' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Sat, 28 Oct 2017 13:37:17 +0000 (15:37 +0200)]
pinctrl: Add skew-delay pin config and bindings
Some pin controllers (such as the Gemini) can control the
expected clock skew and output delay on certain pins with a
sub-nanosecond granularity. This is typically done by shunting
in a number of double inverters in front of or behind the pin.
Make it possible to configure this with a generic binding.
Cc: devicetree@vger.kernel.org Acked-by: Rob Herring <robh@kernel.org> Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Arnd Bergmann [Thu, 2 Nov 2017 14:29:13 +0000 (15:29 +0100)]
pinctrl: armada-37xx: remove unused variable
A cleanup left behind a temporary variable that is now unused:
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c: In function 'armada_37xx_irq_startup':
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c:693:20: error: unused variable 'chip' [-Werror=unused-variable]
Ard Biesheuvel [Fri, 27 Oct 2017 20:21:48 +0000 (21:21 +0100)]
gpio: mb86s70: Revert "Return error if requesting an already assigned gpio"
Commit fd9c963c5661 ("gpio: mb86s70: Return error if requesting an
already assigned gpio") adds code that infers from the state of the
GPIO Pin Function Register (PFR) whether a GPIO has been assigned
already. This assumes that the pin functions are set to 'peripheral'
when the driver is loaded, which is not guaranteed. Also, the GPIO
layer is perfectly capable of keeping track of which GPIOs have been
assigned already, so we shouldn't need this check in the first place.
Cc: Axel Lin <axel.lin@ingics.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Ard Biesheuvel [Fri, 27 Oct 2017 20:21:47 +0000 (21:21 +0100)]
gpio: mb86s7x: share with other SoCs as module
In order to reuse this driver for the Socionext Synquacer SC2A11 SoC,
which inherited this IP from Fujitsu, remove the ARCH_MB86S7X Kconfig
dependency, and revert the changes that prevent it from being built as
a module.
Doug Berger [Tue, 24 Oct 2017 19:54:51 +0000 (12:54 -0700)]
gpio: brcmstb: implement suspend/resume/shutdown
This commit corrects problems with the previous wake implementation
by implementing suspend and resume power management operations and
the driver shutdown operation.
Wake masks are used to keep track of which GPIO should wake the
device. On suspend the GPIO state is saved and the possible wakeup
sources are explicitly unmasked in the hardware. Non-wakeup sources
are explicitly masked so IRQCHIP_MASK_ON_SUSPEND is no longer
necessary. The saved state of the GPIO is restored upon resume.
It is important not to write to the GPIO status register since this
has the effect of clearing bits. The status register is explicitly
removed from the register save and restore to ensure this.
The shutdown operation allows the hardware to be put into the same
quiesced state as the suspend operation and removes the need for
the reboot notifier.
Unfortunately, there appears to be some confusion about whether
a pending disabled wake interrupt should wake the system. If a wake
capable interrupt is disabled using the default "lazy disable"
behavior and it is triggered before the suspend_device_irq call
the interrupt hardware will be acknowledged by mask_ack_irq and the
IRQS_PENDING flag is added to its state. However, the IRQS_PENDING
flag of wake interrupts is not checked to prevent the transition to
suspend and the hardware has been acked which prevents its wakeup.
If the lazy disabled interrupt is triggered after the call to
suspend_device_irqs then the wakeup logic will abort the suspend.
The irq_disable method is defined by this GPIO driver to prevent
lazy disable so that the pending hardware state remains asserted
allowing the hardware to wake and providing a consistent behavior.
In addition, the IRQ_DISABLE_UNLAZY flag is set for the non-wake
parent interrupt as a convenience to prevent the need to add code
to the brcmstb_gpio_irq_handler to support "lazy disable" of the
non-wake parent interrupt when it is disabled during suspend and
resume. Chained interrupt parents are not normally disabled, but
these GPIO devices have different parent interrupts for wake and
non-wake handling. It is convenient to mask the non-wake parent
when suspending to preserve the hardware state for proper wakeup
accounting when the driver is resumed.
Doug Berger [Tue, 24 Oct 2017 19:54:50 +0000 (12:54 -0700)]
gpio: brcmstb: consolidate interrupt domains
The GPIOLIB IRQ chip helpers were very appealing, but badly broke
the 1:1 mapping between a GPIO controller's device_node and its
interrupt domain.
When another device-tree node references a GPIO device as its
interrupt parent, the irq_create_of_mapping() function looks for
the irq domain of the GPIO device and since all bank irq domains
reference the same GPIO device node it always resolves to the irq
domain of the first bank regardless of which bank the number of
the GPIO should resolve. This domain can only map hwirq numbers
0-31 so interrupts on GPIO above that can't be mapped by the
device-tree.
This commit effectively reverts the patch from Gregory Fong [1]
that was accepted upstream and replaces it with a consolidated
irq domain implementation with one larger interrupt domain per
GPIO controller instance spanning multiple GPIO banks based on
an earlier patch [2] also submitted by Gregory Fong.
Doug Berger [Tue, 24 Oct 2017 19:54:49 +0000 (12:54 -0700)]
gpio: brcmstb: correct the configuration of level interrupts
This commit corrects a bug when configuring the GPIO hardware for
IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH interrupt types. The
hardware is now correctly configured to support those types.
Doug Berger [Tue, 24 Oct 2017 19:54:48 +0000 (12:54 -0700)]
gpio: brcmstb: switch to handle_level_irq flow
Reading and writing the gpio bank status register each time a pending
interrupt bit is serviced could cause new pending bits to be cleared
without servicing the associated interrupts.
By using the handle_level_irq flow instead of the handle_simple_irq
flow we get proper handling of interrupt masking as well as acking
of interrupts. The irq_ack method is added to support this.
Doug Berger [Tue, 24 Oct 2017 19:54:47 +0000 (12:54 -0700)]
gpio: brcmstb: release the bgpio lock during irq handlers
The basic memory-mapped GPIO controller lock must be released
before calling the registered GPIO interrupt handlers to allow
the interrupt handlers to access the hardware.
Examples of why a GPIO interrupt handler might want to access
the GPIO hardware include an interrupt that is configured to
trigger on rising and falling edges that needs to read the
current level of the input to know how to respond, or an
interrupt that causes a change in a GPIO output in the same
bank. If the lock is not released before enterring the handler
the hardware accesses will deadlock when they attempt to grab
the lock.
Since the lock is only needed to protect the calculation of
unmasked pending interrupts create a dedicated function to
perform this and hide the complexity.
Doug Berger [Tue, 24 Oct 2017 19:54:46 +0000 (12:54 -0700)]
gpio: brcmstb: allow all instances to be wakeup sources
This commit allows a wakeup parent interrupt to be shared between
instances.
It also removes the redundant can_wake member of the private data
structure by using whether the parent_wake_irq has been defined to
indicate that the GPIO device can wake.
Heiko Stuebner [Sat, 21 Oct 2017 08:53:10 +0000 (10:53 +0200)]
pinctrl: rockchip: Add iomux-route switching support for rk3288
The rk3288 also has one function that can be routed to one of two pins,
the hdmi cec functionality can use either gpio7c0 or gpio7c7.
So add the route switching support for it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: David Wu <david.wu@rock-chips.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Mika Westerberg [Mon, 23 Oct 2017 12:40:26 +0000 (15:40 +0300)]
pinctrl: intel: Add Intel Cedar Fork PCH pin controller support
Intel Cedar Fork PCH is the successor of Intel Denverton PCH but it is
based on the newer GPIO/pinctrl hardware block. Add a new pinctrl/GPIO
driver to support it.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Mika Westerberg [Mon, 23 Oct 2017 12:40:25 +0000 (15:40 +0300)]
pinctrl: intel: Make offset to interrupt status register configurable
Some GPIO blocks have the interrupt status (GPI_IS) offset different
than it normally is, so make it configurable. If no offset is specified
we use the default.
While there remove two unused constants from the core driver.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Sergei Shtylyov [Thu, 12 Oct 2017 21:08:14 +0000 (00:08 +0300)]
gpio-rcar: use devm_ioremap_resource()
Using devm_ioremap_resource() has several advantages over devm_ioremap():
- it checks the passed resource's validity;
- it calls devm_request_mem_region() to check for the resource overlap;
- it prints an error message in case of error.
We can call devm_ioremap_resource() instead of devm_ioremap_nocache()
as ioremap() and ioremap_nocache() are implemented identically on ARM.
Doing this saves 2 LoCs and 80 bytes (AArch64 gcc 4.8.5).
Maxime Ripard [Mon, 9 Oct 2017 20:53:38 +0000 (22:53 +0200)]
pinctrl: sunxi: Disable strict mode for old pinctrl drivers
Old pinctrl drivers will need to disable strict mode for various reasons,
among which:
- Some DT will still have a pinctrl group for each GPIO used, which will
be rejected by pin_request. While we could remove those nodes, we still
have to deal with old DTs.
- Some GPIOs on these boards need to have their pin configuration changed
(for bias or current), and there's no clear migration path
Let's disable the strict mode on those SoCs so that there's no breakage.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Maxime Ripard [Mon, 9 Oct 2017 20:53:37 +0000 (22:53 +0200)]
pinctrl: sunxi: Introduce the strict flag
Our pinctrl device should have had strict set all along. However, it wasn't
the case, and most of our old device trees also have a pinctrl group in
addition to the GPIOs properties, which mean that we can't really turn it
on now.
All our new SoCs don't have that group, so we should still enable that mode
on the newer one though.
In order to enable it by default, add a flag that will allow to disable
that mode that should be set by pinctrl drivers that cannot be migrated.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Thu, 19 Oct 2017 21:30:12 +0000 (23:30 +0200)]
gpio-mmio: Use the new .get_multiple() callback
It is possible to read all lines of a generic MMIO GPIO chip
with a single register read so support this if we are in
native endianness.
Add an especially quirky callback to read multiple lines for
the variants that require you to read values from the
output registers if and only if the line is set as output.
We managed to do that with a maximum of two register reads,
and just one read if the requested lines are all input or all
output.
Linus Walleij [Fri, 20 Oct 2017 14:31:27 +0000 (16:31 +0200)]
gpio: mmio: Make pin2mask() a private business
The vtable call pin2mask() was introducing a vtable function call
in every gpiochip callback for a generic MMIO GPIO chip. This was
not exactly efficient. (Maybe link-time optimization could get rid of
it, I don't know.)
After removing all external calls into this API we can make it a
boolean flag in the struct gpio_chip call and sink the function into
the gpio-mmio driver yielding encapsulation and potential speedups.
Cc: Anton Vorontsov <anton@enomsg.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Fri, 20 Oct 2017 14:08:12 +0000 (16:08 +0200)]
gpio: mpc8xxx: Do not reverse bits using bgpio
The MPC8xxx driver is always instantiating its generic GPIO functions
with the flag BGPIOF_BIG_ENDIAN. This means "big-endian bit order"
and means the bits representing the GPIO lines in the registers are
reversed around 31 bits so line 0 is at bit 31 and so forth down to
line 31 in bit 0.
Instead of looping into the generic MMIO gpio to do the simple
calculation of a bitmask, through a vtable call with two parameters
likely using stack frames etc (unless the compiler optimize it)
and obscuring the view for the programmer, let's just open-code
what the call does. This likely executes faster, saves space and
makes the code easier to read.
Cc: Liu Gang <Gang.Liu@nxp.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Fri, 20 Oct 2017 13:45:34 +0000 (15:45 +0200)]
gpio: brcmstb: Do not use gc->pin2mask()
The pin2mask() accessor only shuffles BIT ORDER in big endian systems,
i.e. the bitstuffing is swizzled big endian so "bit 0" is bit 7 or
bit 15 or bit 31 or so.
The brcmstb only uses big endian BYTE ORDER which will be taken car of
by the ->write_reg() callback.
Linus Walleij [Fri, 20 Oct 2017 12:57:37 +0000 (14:57 +0200)]
gpio: grgpio: Do not use gc->pin2mask()
The pin2mask() accessor only shuffles BIT ORDER in big endian systems,
i.e. the bitstuffing is swizzled big endian so "bit 0" is bit 7 or
bit 15 or bit 31 or so.
The grgpio only uses big endian BYTE ORDER which will be taken car of
by the ->write_reg() callback.
Just use BIT(offset) to assign the bit.
Acked-by: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Fri, 20 Oct 2017 12:42:01 +0000 (14:42 +0200)]
gpio: loongson1: fix bgpio usage
When no flags are given, the native endianness is used to access
the MMIO registers, and the pin2mask() call can simply be
converted to a BIT() call, as per the default pin2mask()
implementation in gpio-mmio.c.
Linus Walleij [Fri, 20 Oct 2017 10:26:51 +0000 (12:26 +0200)]
gpio: dwapb: fix bgpio usage
The DW APB GPIO driver uses the generic GPIO library gpio-mmio,
and initialize the flags as "false", which should be 0.
When no flags are given, the native endianness is used to access
the MMIO registers, and the pin2mask() call can simply be
converted to a BIT() call, as per the default pin2mask()
implementation in gpio-mmio.c.
This GPIO controller is used on UniPhier SoC family.
It also serves as an interrupt controller, but interrupt signals are
just delivered to the parent irqchip without any latching or OR'ing.
This type of hardware can be well described with hierarchy IRQ domain.
One unfortunate thing for this device is that the interrupt mapping to
the interrupt parent is not contiguous.
I asked how DT can describe interrupt mapping between two irqchips [1],
but I could not find a good solution (at least in the framework level).
In fact, irqchip drivers using hierarchy domain generally hard-code the
DT binding of their parent.
After tackling on several approaches such as hard-code of hwirqs,
irq_domain_push_irq(), I ended up with a vendor specific property.
If we come up with a good idea to support this in the framework, we
can migrate over to it, but we can live with a driver-level solution
for now.
This GPIO controller is used on UniPhier SoC family.
The vendor specific property "socionext,interrupt-ranges" is for
specifying interrupt mapping to the parent interrupt controller
because the mapping is not contiguous. It works like "ranges",
but transforms "interrupts" instead of "reg".
Linus Walleij [Fri, 20 Oct 2017 13:20:18 +0000 (15:20 +0200)]
Merge tag 'sh-pfc-for-v4.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: sh-pfc: Updates for v4.15 (take two)
- Add Audio, HSCIF, I2C, and INTC-EX pin groups on R-Car H3 ES2.0,
- Add Audio and PWM pin groups on R-Car D3,
- Add support for RZ/A1M and RZ/A1L,
- Add INTC-EX pin groups on R-Car M3-W,
- Add SDHI voltage switching on RZ/G1E,
- Make bias control and IOCTRL support more generic,
- Add suspend/resume support for R-Car Gen3,
- Small fixes and cleanups.
pinctrl: sh-pfc: Save/restore registers for PSCI system suspend
During PSCI system suspend, R-Car Gen3 SoCs are powered down, and their
pinctrl register state is lost. Note that as the boot loader skips most
initialization after system resume, pinctrl register state differs from
the state encountered during normal system boot, too.
To fix this, save all GPIO and peripheral function select, module
select, drive strength control, bias, and other I/O control registers
during system suspend, and restore them during system resume.
Note that to avoid overhead on platforms not needing it, the
suspend/resume code has a build time dependency on sleep and PSCI
support, and a runtime dependency on PSCI.
Add a generic way to describe IOCTRL registers (for e.g. SD I/O voltage
and time delay control), like is already done for config, drive, and
bias registers.
This makes the sh-pfc core code aware of these registers, which will
ease introducing suspend/resume support later.
pinctrl: sh-pfc: Drop width parameter of sh_pfc_{read,write}_reg()
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().
pinctrl: sh-pfc: Remove matching on plain sh-pfc platform device
As of commit 8682b3c522c639f3 ("sh-pfc: Remove platform device
registration"), plain "sh-pfc" platform devices are no longer created.
Hence remove their match entry, and the now obsolete checks for missing
device IDs and driver data.
Andrew Jeffery [Fri, 20 Oct 2017 02:57:58 +0000 (13:27 +1030)]
gpio: Fix loose spelling
Literally.
I expect "lose" was meant here, rather than "loose", though you could feasibly
use a somewhat uncommon definition of "loose" to mean what would be meant by
"lose": "Loose the hounds" for instance, as in "Release the hounds".
Substituting in "value" for "hounds" gives "release the value", and makes some
sense, but futher substituting back to loose gives "loose the value" which
overall just seems a bit anachronistic.
Instead, use modern, pragmatic English and save a character.
Cc: Russell Currey <ruscur@russell.cc> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Lukas Wunner [Thu, 12 Oct 2017 10:40:10 +0000 (12:40 +0200)]
gpio: Add driver for Maxim MAX3191x industrial serializer
The driver was developed for and tested with the MAX31913 built into
the Revolution Pi by KUNBUS, but should work with all members of the
MAX3191x family:
MAX31910: low power
MAX31911: LED drivers
MAX31912: LED drivers + 2nd voltage monitor + low power
MAX31913: LED drivers + 2nd voltage monitor
MAX31953: LED drivers + 2nd voltage monitor + isolation
MAX31963: LED drivers + 2nd voltage monitor + isolation + buck regulator
Lukas Wunner [Thu, 12 Oct 2017 10:40:10 +0000 (12:40 +0200)]
dt-bindings: Document common property for daisy-chained devices
Many serially-attached GPIO and IIO devices are daisy-chainable.
Examples for GPIO devices are Maxim MAX3191x and TI SN65HVS88x:
https://datasheets.maximintegrated.com/en/ds/MAX31913.pdf
http://www.ti.com/lit/ds/symlink/sn65hvs880.pdf
Examples for IIO devices are TI DAC128S085 and TI DAC161S055:
http://www.ti.com/lit/ds/symlink/dac128s085.pdf
http://www.ti.com/lit/ds/symlink/dac161s055.pdf
We already have drivers for daisy-chainable devices in the tree but
their devicetree bindings are somewhat inconsistent and ill-named:
The gpio-74x164.c driver uses "registers-number" to convey the
number of devices in the daisy-chain. (Sans vendor prefix,
multiple vendors sell compatible versions of this chip.)
The gpio-pisosr.c driver takes a different approach and calculates
the number of devices in the daisy-chain by dividing the common
"ngpios" property (Documentation/devicetree/bindings/gpio/gpio.txt)
by 8 (which assumes that each chip has 8 inputs).
Let's standardize on a common "#daisy-chained-devices" property.
That name was chosen because it's the term most frequently used in
datasheets. (A less frequently used synonym is "cascaded devices".)
Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Thierry Reding [Mon, 16 Oct 2017 12:40:23 +0000 (14:40 +0200)]
pinctrl: armada-37xx: Stop using struct gpio_chip.irq_base
The Armada 37xx driver always initializes the IRQ base to 0, hence the
subtraction is a no-op. Remove the subtraction and thereby the last user
of struct gpio_chip's .irq_base field.
Note that this was also actually a bug and only worked because of the
above assumption. If the IRQ base had been dynamically allocated, the
subtraction would've caused the wrong mask to be generated since the
struct irq_data.hwirq field is an index local to the IRQ domain. As a
result, it should now be safe to also allocate this chip's IRQ base
dynamically, unless there are consumers left that refer to the IRQs by
their global number.
gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags for input
OPEN_DRAIN and OPEN_SOURCE flags only affect the way we drive a GPIO
line, so they only make sense for output mode. Just as we only allow
input mode for event handle requests, don't allow passing open-drain
and open-source flags for any other mode than explicit output.
There's no need to check the validity of handle request flags more
than once, right after copying the data from user. Move the check
out of the for loop and simplify the error path by bailing out before
allocating any resources.
Lukas Wunner [Thu, 12 Oct 2017 10:40:10 +0000 (12:40 +0200)]
gpio: Introduce ->get_multiple callback
SPI-attached GPIO controllers typically read out all inputs in one go.
If callers desire the values of multipe inputs, ideally a single readout
should take place to return the desired values. However the current
driver API only offers a ->get callback but no ->get_multiple (unlike
->set_multiple, which is present). Thus, to read multiple inputs, a
full readout needs to be performed for every single value (barring
driver-internal caching), which is inefficient.
In fact, the lack of a ->get_multiple callback has been bemoaned
repeatedly by the gpio subsystem maintainer:
http://www.spinics.net/lists/linux-gpio/msg10571.html
http://www.spinics.net/lists/devicetree/msg121734.html
Introduce the missing callback. Add corresponding consumer functions
such as gpiod_get_array_value(). Amend linehandle_ioctl() to take
advantage of the newly added infrastructure. Update the documentation.
Lukas Wunner [Thu, 12 Oct 2017 10:40:10 +0000 (12:40 +0200)]
bitops: Introduce assign_bit()
A common idiom is to assign a value to a bit with:
if (value)
set_bit(nr, addr);
else
clear_bit(nr, addr);
Likewise common is the one-line expression variant:
value ? set_bit(nr, addr) : clear_bit(nr, addr);
Commit 9a8ac3ae682e ("dm mpath: cleanup QUEUE_IF_NO_PATH bit
manipulation by introducing assign_bit()") introduced assign_bit()
to the md subsystem for brevity.
Make it available to others, specifically gpiolib and the upcoming
driver for Maxim MAX3191x industrial serializer chips.
As requested by Peter Zijlstra, change the argument order to reflect
traditional "dst = src" in C, hence "assign_bit(nr, addr, value)".
Cc: Bart Van Assche <bart.vanassche@wdc.com> Cc: Alasdair Kergon <agk@redhat.com> Cc: Mike Snitzer <snitzer@redhat.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Neil Brown <neilb@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Acked-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Alan Tull [Wed, 11 Oct 2017 16:34:44 +0000 (11:34 -0500)]
gpio: gpio-dwapb: add optional reset
Some platforms require reset to be released to allow register
access.
Signed-off-by: Alan Tull <atull@kernel.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
[Added DT bindings oneliner for standard reset binding] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Tue, 17 Oct 2017 09:46:09 +0000 (11:46 +0200)]
blackfin: Fix local <asm/gpio.h> includes
When making the pin control submenu globally visible, all kinds
of oddities appear, in blackfin a few files were #including
<linux/gpio.h> and relying on that to pull in <asm/gpio.h>.
This was not working when pin control but not GPIOLIB was
selected resulting in a breakage in allmodconfig. The code these
files were using was still there and defined in <asm/gpio.h>
just not pulle in from just including <linux/gpio.h>
Simply add the required includes explicitly in the blackfin
kernel core and everything compiles fine.
Delete the use of the incorrect <linux/gpio.h> where possible.
Add stubs to <asm/gpio.h> for the functions called from PM:
these should probably also depend on !PINCTRL but since the
global CONFIG_PM symbol is used to compile PM support,
we need some more intrusive thing here, to be tested by
Blackfin maintainers.
Linus Walleij [Wed, 11 Oct 2017 09:57:15 +0000 (11:57 +0200)]
pinctrl: adi2: Fix Kconfig build problem
The build robot is complaining on Blackfin:
drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
pointer to incomplete type 'struct gpio_port_t'
writew(readw(®s->port_fer) & ~BIT(offset),
^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
if (readl(®s->invert_set) & pintbit)
^~
It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
to compile.
The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.
Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local <asm/gpio.h> header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.
Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.
This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.
Linus Walleij [Tue, 17 Oct 2017 09:25:44 +0000 (11:25 +0200)]
gpio: Cut old SX150X Kconfig option
The SX150X driver was moved over to pin control a while back.
The GPIO Kconfig symbol creates a circular dependency since
it requires GPIOLIB and the pin control driver selects GPIOLIB
so get rid of the old annoying Kconfig option.
Jerome Brunet [Thu, 12 Oct 2017 12:40:26 +0000 (14:40 +0200)]
pinctrl: meson: rework pinmux ops
This change prepare the introduction of new meson SoC. This new SoC will
share the same gpio/pinconf registers but the pinmux part will be
different. While the format of the data associated with each pinmux group
will change, the way to handle pinmuxing will be similar.
To deal with this new situation, the meson_pmx_struture is kept but the
data associated to it is now generic. This allows to reuse the basic
functions which would otherwise be copy/pasted in each pinmux driver
(such as getting the name a count of groups and functions) Only the
functions actually using this specific data is taken out of the common
code and is handling the SoC pinmuxing
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Jerome Brunet [Thu, 12 Oct 2017 12:40:25 +0000 (14:40 +0200)]
pinctrl: meson: separate soc drivers
When meson pinctrl is enabled, all meson platforms pinctrl drivers are
built in the kernel, with a significant amount of data.
This leads to situation where pinctrl drivers targeting an architecture
are also compiled and shipped on another one (ex: meson8 - ARM - compiled
and shipped on ARM64 builds). This is a waste of memory we can easily
avoid.
This change makes 4 pinctrl drivers (1 per SoC) out the original single
driver, allowing to compile and ship only the ones required.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Wed, 11 Oct 2017 10:04:35 +0000 (12:04 +0200)]
pinctrl: Do not depend in GPIOLIB, select it
Instead of depends on GPIOLIB and having to run around in
Kconfig menus looking for why your device is not available,
simply select it from the pin control drivers that need it.
The Kconfig for GPIOLIB is improved, selectable and this
should "just work".
Cc: Phil Reid <preid@electromag.com.au> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Cc: Peter Rosin <peda@axentia.se> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
projects / linux.git / log