- 08 Jan, 2020 1 commit
-
-
Boyan Ding authored
Commit 179e5a61 ("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: f702e0b9 ("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 <boyan.j.ding@gmail.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 13 Dec, 2019 32 commits
-
-
Andy Shevchenko authored
Reflect in the driver that it is now a pin control one. While here, update copyright years and authors. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Andy Shevchenko authored
When all preparations are done, we may switch to pin control API. Reviewed-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. Reviewed-by:
-
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 7 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:
-
