- 13 Dec, 2019 30 commits
-
-
Andy Shevchenko authored
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. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com>
-
Andy Shevchenko authored
The introduced callback ->pin_dbg_show() is useful for debugging. Reviewed-by:
-
Andy Shevchenko authored
Add implementation for: - pin control, group information retrieval: count, name and pins - pin muxing: - function information (count, name and groups) - mux setting - GPIO control (enable, disable, set direction) - pin configuration: - pull disable, up and down - any other option is treated as not supported. Reviewed-by: -
Andy Shevchenko authored
We may use now available struct intel_pinctrl in the driver. No functional change implied. Reviewed-by:
-
Andy Shevchenko authored
In order to implement pin control for Intel Lynxpoint, we need data structures in which to store and pass along pin, community and SoC data information. Reviewed-by:
-
Andy Shevchenko authored
Allows querying GPIO direction from the pad config register. If the pad is not in GPIO mode, return an error. Reviewed-by:
-
Andy Shevchenko authored
Instead of playing tricks with registers in the interrupt handler, utilize the IRQ chip core for ACKing interrupts properly. Reviewed-by:
-
Andy Shevchenko authored
There is nothing wrong with requesting pin that owned by ACPI. The only difference is how interrupt status will be reflected. It means that in ACPI mode we may not use pin as GPIO-backed IRQ. Taking above into consideration, move the check from GPIO to IRQ chip callback. Reviewed-by:
-
Andy Shevchenko authored
Consolidate IRQ routines for better maintenance. While here, rename lp_irq_type() to lp_irq_set_type() to be in align with a callback name. Reviewed-by:
-
Andy Shevchenko authored
Consolidate ->remove and ->probe() callbacks for better maintenance. Reviewed-by:
-
Andy Shevchenko authored
We may need this function for other features in the pin control driver. Reviewed-by:
-
Andy Shevchenko authored
Simple type conversion with no functional change implied. Reviewed-by:
-
Andy Shevchenko authored
Convert driver to use memory mapped IO accessors. Reviewed-by:
-
Andy Shevchenko authored
There is no need to keep pointer to struct platform_device, which is container of struct device, because the latter is what have been used everywhere outside of ->probe() path. In any case we may derive pointer to the container when needed. Reviewed-by:
-
Andy Shevchenko authored
A pin in native mode still can be requested as GPIO, though we assume that firmware has configured it properly, which sometimes is not the case. Here we allow turning the pin as GPIO to avoid potential issues, but issue warning that something might be wrong. Reviewed-by:
-
Andy Shevchenko authored
New generations can use 2 bits for mode selector. Update the code to support it. Reviewed-by:
-
Andy Shevchenko authored
The pattern foo = kmalloc(sizeof(*foo), GFP_KERNEL); has an advantage when foo type is changed. Since we are planning a such, better to be prepared by using standard pattern for memory allocation. Reviewed-by:
-
Andy Shevchenko authored
Replace explicit casting by pointer to struct resource with specifier replacement to %pR to print the IO resource. Reviewed-by:
-
Andy Shevchenko authored
There is no need to assign ret variable in ->probe(). Drop useless assignment. Reviewed-by:
-
Andy Shevchenko authored
When we count from 0 it's possible to get into off-by-one error. That's what had happened to this driver. So, correct amount of pins and related typos in the code. Reviewed-by:
-
Andy Shevchenko authored
The Intel Lynxpoint pinctrl driver implements irqchip callbacks which are called with desc->lock raw_spinlock held. In mainline this is fine because spinlock resolves to raw_spinlock. However, running the same code in -rt we will get a BUG() asserted. This is because in -rt spinlocks are preemptible so taking the driver private spinlock in irqchip callbacks causes might_sleep() to trigger. In order to keep -rt happy but at the same time make sure that register accesses get serialized, convert the driver to use raw_spinlock instead. Reviewed-by:
-
Andy Shevchenko authored
Move Lynxpoint GPIO driver under Intel pin control umbrella for further transformation to a real pin control driver. Reviewed-by:
-
Andy Shevchenko authored
We may use now available struct intel_pinctrl in the driver. No functional change implied. Acked-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Andy Shevchenko authored
Use local variable to keep device pointer in order to increase readability of the driver. Acked-by:
-
Andy Shevchenko authored
There is no need to keep pointer to struct platform_device, which is container of struct device, because the latter is what have been used everywhere outside of ->probe() path. In any case we may derive pointer to the container when needed. Acked-by:
-
Andy Shevchenko authored
There are few drivers for Intel SoC GPIO which may utilize the same data structure to describe this IP. Share struct intel_pinctrl for wider user. Acked-by:
-
Matti Vaittinen authored
Use new GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT when returning GPIO direction to GPIO framework. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by:
-
Matti Vaittinen authored
Use new GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT when returning GPIO direction to GPIO framework. Signed-off-by:
-
Matti Vaittinen authored
Use new GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT when returning GPIO direction to GPIO framework. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by:
-
Andy Shevchenko authored
There is a logical continuation of the commit 5fbe5b58 ("gpio: Initialize the irqchip valid_mask with a callback") to split IRQ initialization to hardware and valid mask setup parts. Acked-by:
-
- 09 Dec, 2019 9 commits
-
-
Andy Shevchenko authored
After commit 5ea422750a9f ("pinctrl: baytrail: Pass irqchip when adding gpiochip") the GPIO IRQ chip structure is being initialized under conditional when IRQ resource has been discovered. But that commit left aside the assignment of ->init_valid_mask() callback that is done unconditionally. For sake of consistency and preventing some garbage in GPIO IRQ chip structure group initialization together. Signed-off-by: -
Andy Shevchenko authored
Keeping the IRQ chip definition static shares it with multiple instances of the GPIO chip in the system. This is bad and now we get this warning from GPIO library: "detected irqchip that is shared with multiple gpiochips: please fix the driver." Hence, move the IRQ chip definition from being driver static into the struct intel_pinctrl. So a unique IRQ chip is used for each GPIO chip instance. Fixes: 9f573b98 ("pinctrl: baytrail: Update irq chip operations") Depends-on: ca8a958e ("pinctrl: baytrail: Pass irqchip when adding gpiochip") Signed-off-by:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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:
-
Andy Shevchenko authored
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 <andriy.shevchenko@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Andy Shevchenko authored
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 authored
Update North Community pin list to be more clear about pin functions. Signed-off-by:
-
Hans de Goede authored
Commit 39ce8150 ("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: 39ce8150 ("pinctrl: baytrail: Serialize all register access") Signed-off-by:
-
- 08 Dec, 2019 1 commit
-
-
Linus Torvalds authored
-
