linux/drivers/pinctrl/intel, branch v5.5

pinctrl: sunrisepoint: Add missing Interrupt Status register offset

2020-01-09T11:15:35Z

Commit 179e5a6114cc ("pinctrl: intel: Remove default Interrupt Status offset") removes default interrupt status offset of GPIO controllers, with previous commits explicitly providing the previously default offsets. However, the is_offset value in SPTH_COMMUNITY is missing, preventing related irq from being properly detected and handled. Fixes: f702e0b93cdb ("pinctrl: sunrisepoint: Provide Interrupt Status register offset") Link: https://bugzilla.kernel.org/show_bug.cgi?id=205745 Cc: stable@vger.kernel.org Signed-off-by: Boyan Ding Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko

pinctrl: cherryview: Pass irqchip when adding gpiochip

2019-12-09T10:55:53Z

We need to convert all old gpio irqchips to pass the irqchip setup along when adding the gpio_chip. For more info see drivers/gpio/TODO. For chained irqchips this is a pretty straight-forward conversion. Acked-by: Mika Westerberg Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko

pinctrl: cherryview: Add GPIO <-> pin mapping ranges via callback

2019-12-09T10:55:53Z

When IRQ chip is instantiated via GPIO library flow, the few functions, in particular the ACPI event registration mechanism, on some of ACPI based platforms expect that the pin ranges are initialized to that point. Add GPIO <-> pin mapping ranges via callback in the GPIO library flow. Acked-by: Mika Westerberg Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko

pinctrl: cherryview: Split out irq hw-init into a separate helper function

2019-12-09T10:55:53Z

Split out irq hw-init into a separate chv_gpio_irq_init_hw() function. This is a preparation patch for passing the irqchip when adding the gpiochip. Acked-by: Mika Westerberg Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko

pinctrl: baytrail: Pass irqchip when adding gpiochip

2019-12-09T10:55:53Z

We need to convert all old gpio irqchips to pass the irqchip setup along when adding the gpio_chip. For more info see drivers/gpio/TODO. For chained irqchips this is a pretty straight-forward conversion. Cc: Andy Shevchenko Cc: Mika Westerberg Cc: Thierry Reding Signed-off-by: Linus Walleij Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Reviewed-by: Hans de Goede Tested-by: Hans de Goede

pinctrl: baytrail: Add GPIO <-> pin mapping ranges via callback

2019-12-09T10:55:52Z

When IRQ chip is instantiated via GPIO library flow, the few functions, in particular the ACPI event registration mechanism, on some of ACPI based platforms expect that the pin ranges are initialized to that point. Add GPIO <-> pin mapping ranges via callback in the GPIO library flow. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Reviewed-by: Hans de Goede Tested-by: Hans de Goede

pinctrl: baytrail: Update North Community pin list

2019-12-09T10:42:13Z

Update North Community pin list to be more clear about pin functions. Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg

pinctrl: baytrail: Really serialize all register accesses

2019-12-09T10:42:13Z

Commit 39ce8150a079 ("pinctrl: baytrail: Serialize all register access") added a spinlock around all register accesses because: "There is a hardware issue in Intel Baytrail where concurrent GPIO register access might result reads of 0xffffffff and writes might get dropped completely." Testing has shown that this does not catch all cases, there are still 2 problems remaining 1) The original fix uses a spinlock per byt_gpio device / struct, additional testing has shown that this is not sufficient concurent accesses to 2 different GPIO banks also suffer from the same problem. This commit fixes this by moving to a single global lock. 2) The original fix did not add a lock around the register accesses in the suspend/resume handling. Since pinctrl-baytrail.c is using normal suspend/resume handlers, interrupts are still enabled during suspend/resume handling. Nothing should be using the GPIOs when they are being taken down, _but_ the GPIOs themselves may still cause interrupts, which are likely to use (read) the triggering GPIO. So we need to protect against concurrent GPIO register accesses in the suspend/resume handlers too. This commit fixes this by adding the missing spin_lock / unlock calls. The 2 fixes together fix the Acer Switch 10 SW5-012 getting completely confused after a suspend resume. The DSDT for this device has a bug in its _LID method which reprograms the home and power button trigger- flags requesting both high and low _level_ interrupts so the IRQs for these 2 GPIOs continuously fire. This combined with the saving of registers during suspend, triggers concurrent GPIO register accesses resulting in saving 0xffffffff as pconf0 value during suspend and then when restoring this on resume the pinmux settings get all messed up, resulting in various I2C busses being stuck, the wifi no longer working and often the tablet simply not coming out of suspend at all. Cc: stable@vger.kernel.org Fixes: 39ce8150a079 ("pinctrl: baytrail: Serialize all register access") Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko

pinctrl: lewisburg: Update pin list according to v1.1v6

2019-11-21T14:04:16Z

Version 1.1v6 of pin list has some changes in pin names for Intel Lewisburg. Update the driver accordingly. Note, it reveals the bug in the driver that misses two pins in GPP_L and has rather two extra ones. That's why the ordering of some groups is changed. Fixes: e480b745386e ("pinctrl: intel: Add Intel Lewisburg GPIO support") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20191120133739.54332-1-andriy.shevchenko@linux.intel.com Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

pinctrl: cherryview: Missed type change to unsigned int

2019-11-07T09:12:10Z

We converted 'unsigned' type to be 'unsigned int' in the driver, but there are couple of leftovers. So, finish the task now. Signed-off-by: Andy Shevchenko