kernel/drivers/pinctrl/pinctrl-amd.c, branch linux-5.1.y

pinctrl/amd: fix typo

2019-01-11T12:25:24Z

Fix spelling mistake: "lenght" -> "length" Signed-off-by: Matteo Croce Signed-off-by: Linus Walleij

pinctrl: pinctrl-amd: simplify getting .driver_data

2018-11-05T08:33:32Z

We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang Signed-off-by: Linus Walleij

Merge tag 'v4.19-rc6' into devel

2018-10-01T11:20:45Z

This is the 4.19-rc6 release I needed to merge this in because of extensive conflicts in the MSM and Intel pin control drivers. I know how to resolve them, so let's do it like this. Signed-off-by: Linus Walleij

pinctrl/amd: poll InterruptEnable bits in amd_gpio_irq_set_type

2018-09-25T10:39:19Z

From the AMD BKDG, if WAKE_INT_MASTER_REG.MaskStsEn is set, a software write to the debounce registers of *any* gpio will block wake/interrupt status generation for *all* gpios for a length of time that depends on WAKE_INT_MASTER_REG.MaskStsLength[11:0]. During this period the Interrupt Delivery bit (INTERRUPT_ENABLE) will read as 0. In commit 4c1de0414a1340 ("pinctrl/amd: poll InterruptEnable bits in enable_irq") we tried to fix this same "gpio Interrupts are blocked immediately after writing debounce registers" problem, but incorrectly assumed it only affected the gpio whose debounce was being configured and not ALL gpios. To solve this for all gpios, we move the polling loop from amd_gpio_irq_enable() to amd_gpio_irq_set_type(), while holding the gpio spinlock. This ensures that another gpio operation (e.g. amd_gpio_irq_unmask()) can read a temporarily disabled IRQ and incorrectly disable it while trying to modify some other register bits. Fixes: 4c1de0414a1340 pinctrl/amd: poll InterruptEnable bits in enable_irq Signed-off-by: Daniel Kurtz Signed-off-by: Linus Walleij

pinctrl: Include nothing else

2018-09-14T13:10:57Z

These drivers are GPIO drivers, and the do not need to use the legacy header in , go directly for instead. Replace any use of GPIOF_* with 0/1, these flags are for consumers, not drivers. Get rid of a few gpio_to_irq() users that was littering around the place, use local callbacks or avoid using it at all. Signed-off-by: Linus Walleij

pinctrl/amd: only handle irq if it is pending and unmasked

2018-07-29T20:43:31Z

The AMD pinctrl driver demultiplexes GPIO interrupts and fires off their individual handlers. If one of these GPIO irqs is configured as a level interrupt, and its downstream handler is a threaded ONESHOT interrupt, the GPIO interrupt source is masked by handle_level_irq() until the eventual return of the threaded irq handler. During this time the level GPIO interrupt status will still report as high until the actual gpio source is cleared - both in the individual GPIO interrupt status bit (INTERRUPT_STS_OFF) and in its corresponding "WAKE_INT_STATUS_REG" bit. Thus, if another GPIO interrupt occurs during this time, amd_gpio_irq_handler() will see that the (masked-and-not-yet-cleared) level irq is still pending and incorrectly call its handler again. To fix this, have amd_gpio_irq_handler() check for both interrupts status and mask before calling generic_handle_irq(). Note: Is it possible that this bug was the source of the interrupt storm on Ryzen when using chained interrupts before commit ba714a9c1dea85 ("pinctrl/amd: Use regular interrupt instead of chained")? Signed-off-by: Daniel Kurtz Acked-by: Thomas Gleixner Signed-off-by: Linus Walleij

pinctrl/amd: fix gpio irq level in debugfs

2018-07-29T20:20:15Z

According to the AMD BKDG, the GPIO ActiveLevel bits (10:9) map to: 00 Active High 01 Active Low 10 Active on both edges iff LevelTrig (bit 8) == 0 11 Reserved The current code has a bug where it interprets 00 => Active Low, and 01 => Active High. Fix the bug, restrict "Active on both" to just the edge trigger case, and refactor a bit to make the logic more readable. Signed-off-by: Daniel Kurtz Signed-off-by: Linus Walleij

pinctrl/amd: poll InterruptEnable bits in enable_irq

2018-03-26T09:09:49Z

In certain cases interrupt enablement will be delayed relative to when the InterruptEnable bits are written. One example of this is when a GPIO's "debounce" logice is first enabled. After enabling debounce, there is a 900 us "warm up" period during which InterruptEnable[0] (bit 11) will read as 0 despite being written 1. During this time InterruptSts will not be updated, nor will interrupts be delivered, even if the GPIO's interrupt configuration has been written to the register. To work around this delay, poll the InterruptEnable bits after setting them to ensure interrupts have truly been enabled in hardware before returning from the irq_enable handler. Signed-off-by: Daniel Kurtz Signed-off-by: Linus Walleij

pinctrl/amd: add get_direction handler

2018-02-22T14:52:19Z

On boot, gpiochip_add_data() initializes the FLAG_IS_OUT bit in desc->flags iff its gpio_chip does not have ->direction_input() handler, else it is initialized to 0, which implies the GPIO is an "input". Later, the sysfs "direction" handler will use gpiod_get_direction() to get the current direction, but if no ->get_direction() handler is installed, the result will just be the current (initial) value of flags, which will always be OUT irregardless of the initial register value. Add a get_direction() handler to pinctrl-amd to fix this and always provide the correct value for direction. Signed-off-by: Daniel Kurtz Signed-off-by: Linus Walleij

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

2017-11-16T18:57:11Z

Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v4.15 kernel cycle: Core: - The pin control Kconfig entry PINCTRL is now turned into a menuconfig option. This obviously has the implication of making the subsystem menu visible in menuconfig. This is happening because of two things: (a) Intel have started to deploy and depend on pin controllers in a way that is affecting users directly. This happens on the highly integrated laptop chipsets named after geographical places: baytrail, broxton, cannonlake, cedarfork, cherryview, denverton, geminilake, lewisburg, merrifield, sunrisepoint... It started a while back and now it is ever more evident that this is crucial infrastructure for x86 laptops and not an embedded obscurity anymore. Users need to be aware. (b) Pin control expanders on I2C and SPI that are arch-agnostic. Currently Semtech SX150X and Microchip MCP28x08 but more are expected. Users will have to be able to configure these in directly for their set-up. - Just go and select GPIOLIB now that we made sure that GPIOLIB is a very vanilla subsystem. Do not depend on it, if we need it, select it. - Exposing the pin control subsystem in menuconfig uncovered a bunch of obscure bugs that are now hopefully fixed, all more or less pertaining to Blackfin. - Unified namespace for cross-calls between pin control and GPIO. - New support for clock skew/delay generic DT bindings and generic pin config options for this. - Minor documentation improvements. Various: - The Renesas SH-PFC pin controller has evolved a lot. It seems Renesas are churning out new SoCs by the minute. - A bunch of non-critical fixes for the Rockchip driver. - Improve the use of library functions instead of open coding. - Support the MCP28018 variant in the MCP28x08 driver. - Static constifying" * tag 'pinctrl-v4.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (91 commits) pinctrl: gemini: Fix missing pad descriptions pinctrl: Add some depends on HAS_IOMEM pinctrl: samsung/s3c24xx: add CONFIG_OF dependency pinctrl: gemini: Fix GMAC groups pinctrl: qcom: spmi-gpio: Add pmi8994 gpio support pinctrl: ti-iodelay: remove redundant unused variable dev pinctrl: max77620: Use common error handling code in max77620_pinconf_set() pinctrl: gemini: Implement clock skew/delay config pinctrl: gemini: Use generic DT parser pinctrl: Add skew-delay pin config and bindings pinctrl: armada-37xx: Add edge both type gpio irq support pinctrl: uniphier: remove eMMC hardware reset pin-mux pinctrl: rockchip: Add iomux-route switching support for rk3288 pinctrl: intel: Add Intel Cedar Fork PCH pin controller support pinctrl: intel: Make offset to interrupt status register configurable pinctrl: sunxi: Enforce the strict mode by default pinctrl: sunxi: Disable strict mode for old pinctrl drivers pinctrl: sunxi: Introduce the strict flag pinctrl: sh-pfc: Save/restore registers for PSCI system suspend pinctrl: sh-pfc: r8a7796: Use generic IOCTRL register description ...