BMC/Intel-BMC/linux.git/drivers/gpio, branch dev-4.17

Merge tag 'v4.17.14' into dev-4.17

2018-08-15T00:05:27+00:00

This is the 4.17.14 stable release Signed-off-by: Joel Stanley

gpio: uniphier: set legitimate irq trigger type in .to_irq hook

2018-08-03T05:48:03+00:00

commit bbfbf04c2d4ef673f657175456f6693c9225748a upstream. If a GPIO chip is a part of a hierarchy IRQ domain, there is no way to specify the trigger type when gpio(d)_to_irq() allocates an interrupt on-the-fly. Currently, uniphier_gpio_to_irq() sets IRQ_TYPE_NONE, but it causes an error in the .alloc() hook of the parent domain. (drivers/irq/irq-uniphier-aidet.c) Even if we change irq-uniphier-aidet.c to accept the NONE type, GIC complains about it since commit 83a86fbb5b56 ("irqchip/gic: Loudly complain about the use of IRQ_TYPE_NONE"). Instead, use IRQ_TYPE_LEVEL_HIGH as a temporary value when an irq is allocated. irq_set_irq_type() will override it when the irq is really requested. Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver") Reported-by: Katsuhiro Suzuki Signed-off-by: Masahiro Yamada Tested-by: Katsuhiro Suzuki Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: of: Handle fixed regulator flags properly

2018-08-03T05:48:03+00:00

commit 906402a44b5d090e9c330c562b8aa65c80790ccc upstream. This fixes up the handling of fixed regulator polarity inversion flags: while I remembered to fix it for the undocumented "reg-fixed-voltage" I forgot about the official "regulator-fixed" binding, there are two ways to do a fixed regulator. The error was noticed and fixed. Fixes: a603a2b8d86e ("gpio: of: Add special quirk to parse regulator flags") Cc: Mark Brown Cc: Thierry Reding Reported-by: Thierry Reding Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: aspeed: Add gpio register data to copro request

2018-07-05T00:14:40+00:00

This synchronises the ASPEED GPIO driver with the version merged upstream. OpenBMC-Staging-Count: 1 Signed-off-by: Joel Stanley

gpio: aspeed: Add interfaces for co-processor to grab GPIOs

2018-06-19T06:24:16+00:00

On the Aspeed chip, the GPIOs can be under control of the ARM chip or of the ColdFire coprocessor. (There's a third command source, the LPC bus, which we don't use or support yet). The control of which master is allowed to modify a given GPIO is per-bank (8 GPIOs). Unfortunately, systems already exist for which we want to use GPIOs of both sources in the same bank. This provides an API exported by the gpio-aspeed driver that an aspeed coprocessor driver can use to "grab" some GPIOs for use by the coprocessor, and allow the coprocessor driver to provide callbacks for arbitrating access. Once at least one GPIO of a given bank has been "grabbed" by the coprocessor, the entire bank is marked as being under coprocessor control. It's command source is switched to the coprocessor. If the ARM then tries to write to a GPIO in such a marked bank, the provided callbacks are used to request access from the coprocessor driver, which is responsible to doing whatever is necessary to "pause" the coprocessor or prevent it from trying to use the GPIOs while the ARM is doing its accesses. During that time, the command source for the bank is temporarily switched back to the ARM. OpenBMC-Staging-Count: 1 Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

gpio: aspeed: Add command source registers

2018-06-19T06:24:10+00:00

This adds the definitions for the command source registers and a helper to set them. Those registers allow to control which bus master on the SoC is allowed to modify a given bank of GPIOs and will be used by subsequent patches. OpenBMC-Staging-Count: 1 Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

gpio: aspeed: Add "Read Data" register to read the write latch

2018-06-19T06:24:06+00:00

The Aspeed GPIO hardware has a quirk: the value register, for an output GPIO, doesn't contain the last value written (the write latch content) but the sampled input value. This means that when reading back shortly after writing, you can get an incorrect value as the input value is delayed by a few synchronizers. The HW supports a separate read-only register "Data Read Register" which allows you to read the write latch instead. This adds the definition for it, and uses it for the initial population of the GPIO value cache. It will be used more in subsequent patches. can be OpenBMC-Staging-Count: 1 Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

gpio: aspeed: Rework register type accessors

2018-06-19T06:23:38+00:00

Use a single accessor function for all register types instead of several spread around. This will make it easier/cleaner to introduce new registers and keep the mechanism in one place. The big switch/case is optimized at compile time since the switch value is a constant. OpenBMC-Staging-Count: 1 Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

gpio/aspeed: Use a cache of output data registers

2018-06-19T03:05:38+00:00

The current driver does a read/modify/write of the output registers when changing a bit in __aspeed_gpio_set(). This is sub-optimal for a couple of reasons: - If any of the neighbouring GPIOs (sharing the shared register) isn't (yet) configured as an output, it will read the current input value, and then apply it to the output latch, which may not be what the user expects. There should be no bug in practice as aspeed_gpio_dir_out() will establish a new value but it's not great either. - The GPIO block in the aspeed chip is clocked rather slowly (typically 25Mhz). That extra MMIO read halves the maximum speed at which we can toggle the GPIO. This provides a significant performance improvement to the GPIO based FSI master. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley

gpio/aspeed: Set output latch before changing direction

2018-06-19T03:05:38+00:00

In aspeed_gpio_dir_out(), we need to establish the new output value in the output latch *before* we change the direction to output in order to avoid a glitch on the output line if the previous value of the latch was different. Signed-off-by: Benjamin Herrenschmidt Reviewed-by: Christopher Bostic Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley