#
c2ddeb29 |
|
25-Mar-2024 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
genirq: Introduce IRQF_COND_ONESHOT and use it in pinctrl-amd There is a problem when a driver requests a shared interrupt line to run a threaded handler on it without IRQF_ONESHOT set if that flag has been set already for the IRQ in question by somebody else. Namely, the request fails which usually leads to a probe failure even though the driver might have worked just fine with IRQF_ONESHOT, but it does not want to use it by default. Currently, the only way to handle this is to try to request the IRQ without IRQF_ONESHOT, but with IRQF_PROBE_SHARED set and if this fails, try again with IRQF_ONESHOT set. However, this is a bit cumbersome and not very clean. When commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") switched the ACPI subsystem over to using a threaded interrupt handler for the SCI, it had to use IRQF_ONESHOT for it because that's required due to the way the SCI handler works (it needs to walk all of the enabled GPEs before the interrupt line can be unmasked). The SCI interrupt line is not shared with other users very often due to the SCI handling overhead, but on sone systems it is shared and when the other user of it attempts to install a threaded handler, a flags mismatch related to IRQF_ONESHOT may occur. As it turned out, that happened to the pinctrl-amd driver and so commit 4451e8e8415e ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request") attempted to address the issue by adding IRQF_ONESHOT to the interrupt flags in that driver, but this is now causing an IRQF_ONESHOT-related mismatch to occur on another system which cannot boot as a result of it. Clearly, pinctrl-amd can work with IRQF_ONESHOT if need be, but it should not set that flag by default, so it needs a way to indicate that to the interrupt subsystem. To that end, introdcuce a new interrupt flag, IRQF_COND_ONESHOT, which will only have effect when the IRQ line is shared and IRQF_ONESHOT has been set for it already, in which case it will be promoted to the latter. This is sufficient for drivers sharing the interrupt line with the SCI as it is requested by the ACPI subsystem before any drivers are probed, so they will always see IRQF_ONESHOT set for the interrupt in question. Fixes: 4451e8e8415e ("pinctrl: amd: Add IRQF_ONESHOT to the interrupt request") Reported-by: Francisco Ayala Le Brun <francisco@videowindow.eu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: 6.8+ <stable@vger.kernel.org> # 6.8+ Closes: https://lore.kernel.org/lkml/CAN-StX1HqWqi+YW=t+V52-38Mfp5fAz7YHx4aH-CQjgyNiKx3g@mail.gmail.com/ Link: https://lore.kernel.org/r/12417336.O9o76ZdvQC@kreacher
|
#
4451e8e8 |
|
22-Jan-2024 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Add IRQF_ONESHOT to the interrupt request On some systems the interrupt is shared between GPIO controller and ACPI SCI. When the interrupt is shared with the ACPI SCI the flags need to be identical. This should fix the GPIO controller failing to work after commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI"). ``` [ 0.417335] genirq: Flags mismatch irq 9. 00000088 (pinctrl_amd) vs. 00002080 (acpi) [ 0.420073] amd_gpio: probe of AMDI0030:00 failed with error -16 ``` Cc: Rafael J. Wysocki <rafael@kernel.org> Reported-by: Christian Heusel <christian@heusel.eu> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218407 Fixes: 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") Link: https://lore.kernel.org/linux-acpi/CAJZ5v0iRqUXeuKmC_+dAJtDBLWQ3x15n4gRH48y7MEaLoXF+UA@mail.gmail.com/T/#mc5506014141b61e472b24e095889535a04458083 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Tested-by: Christian Heusel <christian@heusel.eu> Link: https://lore.kernel.org/r/20240123180818.3994-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2fff0b5e |
|
02-Dec-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Mask non-wake source pins with interrupt enabled at suspend If a pin isn't marked as a wake source processing any interrupts is just going to destroy battery life. The APU may wake up from a hardware sleep state to process the interrupt but not return control to the OS. Mask interrupt for all non-wake source pins at suspend. They'll be re-enabled at resume. Reported-and-tested-by: Marcus Aram <marcus+oss@oxar.nl> Reported-and-tested-by: Mark Herbert <mark.herbert42@gmail.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2812 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20231203032431.30277-3-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
23a35fd9 |
|
09-Oct-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pinctrl: amd: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231009083856.222030-9-u.kleine-koenig@pengutronix.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
87b549ef |
|
17-Jul-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Don't show `Invalid config param` errors On some systems amd_pinconf_set() is called with parameters 0x8 (PIN_CONFIG_DRIVE_PUSH_PULL) or 0x14 (PIN_CONFIG_PERSIST_STATE) which are not supported by pinctrl-amd. Don't show an err message when called with an invalid parameter, downgrade this to debug instead. Cc: stable@vger.kernel.org # 6.1 Fixes: 635a750d958e1 ("pinctrl: amd: Use amd_pinconf_set() for all config options") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230717201652.17168-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6bc3462a |
|
18-Aug-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Mask wake bits on probe again Shubhra reports that their laptop is heating up over s2idle. Even though it's getting into the deepest state, it appears to be having spurious wakeup events. While debugging a tangential issue with the RTC Carsten reports that recent 6.1.y based kernel face a similar problem. Looking at acpidump and GPIO register comparisons these spurious wakeup events are from the GPIO associated with the I2C touchpad on both laptops and occur even when the touchpad is not marked as a wake source by the kernel. This means that the boot firmware has programmed these bits and because Linux didn't touch them lead to spurious wakeup events from that GPIO. To fix this issue, restore most of the code that previously would clear all the bits associated with wakeup sources. This will allow the kernel to only program the wake up sources that are necessary. This is similar to what was done previously; but only the wake bits are cleared by default instead of interrupts and wake bits. If any other problems are reported then it may make sense to clear interrupts again too. Cc: Sachi King <nakato@nakato.io> Cc: stable@vger.kernel.org Cc: Thorsten Leemhuis <regressions@leemhuis.info> Fixes: 65f6c7c91cb2 ("pinctrl: amd: Revert "pinctrl: amd: disable and mask interrupts on probe"") Reported-by: Shubhra Prakash Nandi <email2shubhra@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217754 Reported-by: Carsten Hatger <xmb8dsv4@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217626#c28 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230818144850.1439-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
283c5ce7 |
|
05-Jul-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Unify debounce handling into amd_pinconf_set() Debounce handling is done in two different entry points in the driver. Unify this to make sure that it's always handled the same. Tested-by: Jan Visser <starquake@linuxeverywhere.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230705133005.577-5-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3f62312d |
|
05-Jul-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Drop pull up select configuration pinctrl-amd currently tries to program bit 19 of all GPIOs to select either a 4kΩ or 8hΩ pull up, but this isn't what bit 19 does. Bit 19 is marked as reserved, even in the latest platforms documentation. Drop this programming functionality. Tested-by: Jan Visser <starquake@linuxeverywhere.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230705133005.577-4-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
635a750d |
|
05-Jul-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Use amd_pinconf_set() for all config options On ASUS TUF A16 it is reported that the ITE5570 ACPI device connected to GPIO 7 is causing an interrupt storm. This issue doesn't happen on Windows. Comparing the GPIO register configuration between Windows and Linux bit 20 has been configured as a pull up on Windows, but not on Linux. Checking GPIO declaration from the firmware it is clear it *should* have been a pull up on Linux as well. ``` GpioInt (Level, ActiveLow, Exclusive, PullUp, 0x0000, "\\_SB.GPIO", 0x00, ResourceConsumer, ,) { // Pin list 0x0007 } ``` On Linux amd_gpio_set_config() is currently only used for programming the debounce. Actually the GPIO core calls it with all the arguments that are supported by a GPIO, pinctrl-amd just responds `-ENOTSUPP`. To solve this issue expand amd_gpio_set_config() to support the other arguments amd_pinconf_set() supports, namely `PIN_CONFIG_BIAS_PULL_DOWN`, `PIN_CONFIG_BIAS_PULL_UP`, and `PIN_CONFIG_DRIVE_STRENGTH`. Reported-by: Nik P <npliashechnikov@gmail.com> Reported-by: Nathan Schulte <nmschulte@gmail.com> Reported-by: Friedrich Vock <friedrich.vock@gmx.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217336 Reported-by: dridri85@gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217493 Link: https://lore.kernel.org/linux-input/20230530154058.17594-1-friedrich.vock@gmx.de/ Tested-by: Jan Visser <starquake@linuxeverywhere.org> Fixes: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230705133005.577-3-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0d5ace1a |
|
05-Jul-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Only use special debounce behavior for GPIO 0 It's uncommon to use debounce on any other pin, but technically we should only set debounce to 0 when working off GPIO0. Cc: stable@vger.kernel.org Tested-by: Jan Visser <starquake@linuxeverywhere.org> Fixes: 968ab9261627 ("pinctrl: amd: Detect internal GPIO0 debounce handling") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230705133005.577-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
65f6c7c9 |
|
21-Apr-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Revert "pinctrl: amd: disable and mask interrupts on probe" commit 4e5a04be88fe ("pinctrl: amd: disable and mask interrupts on probe") was well intentioned to mask a firmware issue on a surface laptop, but it has a few problems: 1. It had a bug in the loop handling for iteration 63 that lead to other problems with GPIO0 handling. 2. It disables interrupts that are used internally by the SOC but masked by default. 3. It masked a real firmware problem in some chromebooks that should have been caught during development but wasn't. There has been a lot of other development around s2idle; particularly around handling of the spurious wakeups. If there is still a problem on the original reported surface laptop it should be avoided by adding a quirk to gpiolib-acpi for that system instead. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230421120625.3366-5-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0cf9e48f |
|
21-Apr-2023 |
Kornel Dulęba <korneld@chromium.org> |
pinctrl: amd: Detect and mask spurious interrupts Leverage gpiochip_line_is_irq to check whether a pin has an irq associated with it. The previous check ("irq == 0") didn't make much sense. The irq variable refers to the pinctrl irq, and has nothing do to with an individual pin. On some systems, during suspend/resume cycle, the firmware leaves an interrupt enabled on a pin that is not used by the kernel. Without this patch that caused an interrupt storm. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217315 Signed-off-by: Kornel Dulęba <korneld@chromium.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230421120625.3366-4-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a855724d |
|
21-Apr-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Fix mistake in handling clearing pins at startup commit 4e5a04be88fe ("pinctrl: amd: disable and mask interrupts on probe") had a mistake in loop iteration 63 that it would clear offset 0xFC instead of 0x100. Offset 0xFC is actually `WAKE_INT_MASTER_REG`. This was clearing bits 13 and 15 from the register which significantly changed the expected handling for some platforms for GPIO0. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217315 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230421120625.3366-3-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
968ab926 |
|
21-Apr-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Detect internal GPIO0 debounce handling commit 4e5a04be88fe ("pinctrl: amd: disable and mask interrupts on probe") had a mistake in loop iteration 63 that it would clear offset 0xFC instead of 0x100. Offset 0xFC is actually `WAKE_INT_MASTER_REG`. This was clearing bits 13 and 15 from the register which significantly changed the expected handling for some platforms for GPIO0. commit b26cd9325be4 ("pinctrl: amd: Disable and mask interrupts on resume") actually fixed this bug, but lead to regressions on Lenovo Z13 and some other systems. This is because there was no handling in the driver for bit 15 debounce behavior. Quoting a public BKDG: ``` EnWinBlueBtn. Read-write. Reset: 0. 0=GPIO0 detect debounced power button; Power button override is 4 seconds. 1=GPIO0 detect debounced power button in S3/S5/S0i3, and detect "pressed less than 2 seconds" and "pressed 2~10 seconds" in S0; Power button override is 10 seconds ``` Cross referencing the same master register in Windows it's obvious that Windows doesn't use debounce values in this configuration. So align the Linux driver to do this as well. This fixes wake on lid when WAKE_INT_MASTER_REG is properly programmed. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=217315 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230421120625.3366-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c9a23641 |
|
02-Jun-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Use pm_pr_dbg to show debugging messages To make the GPIO tracking around suspend easier for end users to use, link it with pm_debug_messages. This will make discovering sources of spurious GPIOs around suspend easier. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
010f493d |
|
27-Mar-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Add fields for interrupt status and wake status If the firmware has misconfigured a GPIO it may cause interrupt status or wake status bits to be set and not asserted. Add these to debug output to catch this case. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230328174231.8924-3-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
75358cf3 |
|
27-Mar-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Adjust debugfs output More fields are to be added, so to keep the display from being too busy, adjust it. 1) Add a header to all columns 2) Except for interrupt, when fields have no data show empty 3) Remove otherwise blank whitespace Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230328174231.8924-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
feb7e8cb |
|
07-Mar-2023 |
Nick Alcock <nick.alcock@oracle.com> |
pinctrl: amd: remove MODULE_LICENSE in non-modules Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Suggested-by: Luis Chamberlain <mcgrof@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com> Cc: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
|
#
534e4658 |
|
11-Apr-2023 |
Kornel Dulęba <korneld@chromium.org> |
Revert "pinctrl: amd: Disable and mask interrupts on resume" This reverts commit b26cd9325be4c1fcd331b77f10acb627c560d4d7. This patch introduces a regression on Lenovo Z13, which can't wake from the lid with it applied; and some unspecified AMD based Dell platforms are unable to wake from hitting the power button Signed-off-by: Kornel Dulęba <korneld@chromium.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230411134932.292287-1-korneld@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b26cd932 |
|
20-Mar-2023 |
Kornel Dulęba <korneld@chromium.org> |
pinctrl: amd: Disable and mask interrupts on resume This fixes a similar problem to the one observed in: commit 4e5a04be88fe ("pinctrl: amd: disable and mask interrupts on probe"). On some systems, during suspend/resume cycle firmware leaves an interrupt enabled on a pin that is not used by the kernel. This confuses the AMD pinctrl driver and causes spurious interrupts. The driver already has logic to detect if a pin is used by the kernel. Leverage it to re-initialize interrupt fields of a pin only if it's not used by us. Cc: stable@vger.kernel.org Fixes: dbad75dd1f25 ("pinctrl: add AMD GPIO driver support.") Signed-off-by: Kornel Dulęba <korneld@chromium.org> Link: https://lore.kernel.org/r/20230320093259.845178-1-korneld@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
df72b4a6 |
|
08-Dec-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Add Z-state wake control bits GPIO registers include Bit 27 for WakeCntrlZ used to enable wake in Z state. Hence add Z-state wake control bits to debugfs output to debug and analyze Z-states problems. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Guruvendra Punugupati <Guruvendra.Punugupati@amd.com> Link: https://lore.kernel.org/r/20221208093704.1151928-1-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c6e0679b |
|
21-Jan-2023 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Fix debug output for debounce time If one GPIO has debounce enabled but future GPIOs in the list don't have debounce the time never gets reset and shows wrong value. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230121134812.16637-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1d66e379 |
|
13-Oct-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Add dynamic debugging for active GPIOs Some laptops have been reported to wake up from s2idle when plugging in the AC adapter or by closing the lid. This is a surprising behavior that is further clarified by commit cb3e7d624c3ff ("PM: wakeup: Add extra debugging statement for multiple active IRQs"). With that commit in place the following interaction can be seen when the lid is closed: [ 28.946038] PM: suspend-to-idle [ 28.946083] ACPI: EC: ACPI EC GPE status set [ 28.946101] ACPI: PM: Rearming ACPI SCI for wakeup [ 28.950152] Timekeeping suspended for 3.320 seconds [ 28.950152] PM: Triggering wakeup from IRQ 9 [ 28.950152] ACPI: EC: ACPI EC GPE status set [ 28.950152] ACPI: EC: ACPI EC GPE dispatched [ 28.995057] ACPI: EC: ACPI EC work flushed [ 28.995075] ACPI: PM: Rearming ACPI SCI for wakeup [ 28.995131] PM: Triggering wakeup from IRQ 9 [ 28.995271] ACPI: EC: ACPI EC GPE status set [ 28.995291] ACPI: EC: ACPI EC GPE dispatched [ 29.098556] ACPI: EC: ACPI EC work flushed [ 29.207020] ACPI: EC: ACPI EC work flushed [ 29.207037] ACPI: PM: Rearming ACPI SCI for wakeup [ 29.211095] Timekeeping suspended for 0.739 seconds [ 29.211095] PM: Triggering wakeup from IRQ 9 [ 29.211079] PM: Triggering wakeup from IRQ 7 [ 29.211095] ACPI: PM: ACPI non-EC GPE wakeup [ 29.211095] PM: resume from suspend-to-idle * IRQ9 on this laptop is used for the ACPI SCI. * IRQ7 on this laptop is used for the GPIO controller. What has occurred is when the lid was closed the EC woke up the SoC from it's deepest sleep state and the kernel's s2idle loop processed all EC events. When it was finished processing EC events, it checked for any other reasons to wake (break the s2idle loop). The IRQ for the GPIO controller was active so the loop broke, and then this IRQ was processed. This is not a kernel bug but it is certainly a surprising behavior, and to better debug it we should have a dynamic debugging message that we can enact to catch it. Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20221013134729.5592-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f460c701 |
|
19-Sep-2022 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
pinctrl: amd: Use generic_handle_irq_safe() On PREEMPT_RT enabled kernels the demultiplex interrupt handler is force threaded and runs with interrupts enabled. The invocation of generic_handle_domain_irq() with interrupts enabled triggers a lockdep warning due to a non-irq safe lock acquisition. Instead of disabling interrupts on the driver level, use generic_handle_domain_irq_safe(). [ tglx: Split out from combo patch ] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/YnkfWFzvusFFktSt@linutronix.de Link: https://bugzilla.kernel.org/show_bug.cgi?id=215954
|
#
3160b37e |
|
30-Aug-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: change dev_warn to dev_dbg for additional feature support Use dev_dbg instead of dev_warn for additional support of pinmux feature. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Link: https://lore.kernel.org/r/20220830110525.1933198-1-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
76e55d93 |
|
23-Aug-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Pick some different unicode symbols Feedback from Kent had showed some better selections for symbols to use for pinctrl-amd debugfs output. Adopt some of those instead. Fixes: e8129a076a50 ("pinctrl: amd: Use unicode for debugfs output") Suggested-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220823230753.14799-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
df91ffe8 |
|
01-Aug-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Fix an unused variable `char *output_enable` is no longer used once switching to unicode output. Fixes: e8129a076a50 ("pinctrl: amd: Use unicode for debugfs output") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220801144952.141-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e8129a07 |
|
22-Jul-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Use unicode for debugfs output The output is currently split across two lines making it more difficult to parse unless the newlines are removed between pins or it's read in by a parser like Libreoffice Calc or Google docs. To make it easier to follow to the naked eye in a terminal window: * drop the newline in the middle of pin definitions * shorten all output using unicode characters * align all pipe delimitters * output the same phrase even for disabled functions (but with a ∅ character) Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220722220810.28894-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dc24b753 |
|
22-Jul-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Fix newline declaration in debugfs output Currently the debugfs output for pinctrl-amd puts the first line combined with "GPIO bank". This makes it a little harder to process as the file needs to be manually corrected for the mistake. Change this to be a new line character instead. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220722220810.28894-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6011c7e9 |
|
12-Jun-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Remove contact information Remove contact information. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Link: https://lore.kernel.org/r/20220613064127.220416-4-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b8c824a8 |
|
12-Jun-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Don't save/restore interrupt status and wake status bits Saving/restoring interrupt and wake status bits across suspend can cause the suspend to fail if an IRQ is serviced across the suspend cycle. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Fixes: 79d2c8bede2c ("pinctrl/amd: save pin registers over suspend/resume") Link: https://lore.kernel.org/r/20220613064127.220416-3-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
21793d22 |
|
12-Jun-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Use devm_platform_get_and_ioremap_resource Use devm_platform_get_and_ioremap_resource() to simplify code. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Link: https://lore.kernel.org/r/20220613064127.220416-2-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
72440158 |
|
01-Jun-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Implement pinmux functionality Provide pinmux functionality by implementing pinmux_ops. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220601152900.1012813-7-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79bb5c7f |
|
01-Jun-2022 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Add amd_get_iomux_res function Presently there is no way to change pinmux configuration run time. Hence add a function to get IOMUX resource which can be used to configure IOMUX GPIO pins run time. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220601152900.1012813-6-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6173e56f |
|
19-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
pinctrl: amd: Make the irqchip immutable Prevent gpiolib from messing with the irqchip by advertising the irq_chip structure as immutable, making it const, and adding the various calls that gpiolib relies upon. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-9-maz@kernel.org
|
#
8a8d6bbe |
|
14-Dec-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
pinctrl: Get rid of duplicate of_node assignment in the drivers GPIO library does copy the of_node from the parent device of the GPIO chip, there is no need to repeat this in the individual drivers. Remove these assignment all at once. For the details one may look into the of_gpio_dev_init() implementation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211214125855.33207-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2d54067f |
|
31-Oct-2021 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Fix wakeups when IRQ is shared with SCI On some Lenovo AMD Gen2 platforms the IRQ for the SCI and pinctrl drivers are shared. Due to how the s2idle loop handling works, this case needs an extra explicit check whether the interrupt was caused by SCI or by the GPIO controller. To fix this rework the existing IRQ handler function to function as a checker and an IRQ handler depending on the calling arguments. BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1738 Reported-by: Joerie de Gram <j.de.gram@gmail.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Link: https://lore.kernel.org/r/20211101014853.6177-2-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4e5a04be |
|
08-Oct-2021 |
Sachi King <nakato@nakato.io> |
pinctrl: amd: disable and mask interrupts on probe Some systems such as the Microsoft Surface Laptop 4 leave interrupts enabled and configured for use in sleep states on boot, which cause unexpected behaviour such as spurious wakes and failed resumes in s2idle states. As interrupts should not be enabled until they are claimed and explicitly enabled, disabling any interrupts mistakenly left enabled by firmware should be safe. Signed-off-by: Sachi King <nakato@nakato.io> Link: https://lore.kernel.org/r/20211009033240.21543-1-nakato@nakato.io Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
acd47b9f |
|
31-Aug-2021 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Handle wake-up interrupt Enable/disable power management wakeup mode, which is disabled by default. enable_irq_wake enables wakes the system from sleep. Hence added enable/disable irq_wake to handle wake-up interrupt. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210831120613.1514899-3-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7e6f8d6f |
|
31-Aug-2021 |
Basavaraj Natikar <Basavaraj.Natikar@amd.com> |
pinctrl: amd: Add irq field data pinctrl_amd use gpiochip_get_data() to get their local state containers back from the gpiochip passed as amd_gpio chip data. Hence added irq field data to get directly using amd_gpio chip data. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Tested-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20210831120613.1514899-2-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a9cb09b7 |
|
04-May-2021 |
Marc Zyngier <maz@kernel.org> |
pinctrl: Bulk conversion to generic_handle_domain_irq() Wherever possible, replace constructs that match either generic_handle_irq(irq_find_mapping()) or generic_handle_irq(irq_linear_revmap()) to a single call to generic_handle_domain_irq(). Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
c4b68e51 |
|
09-Aug-2021 |
Mario Limonciello <mario.limonciello@amd.com> |
pinctrl: amd: Fix an issue with shutdown when system set to s0ix IRQs are getting armed on shutdown causing the system to immediately wake back up. Link: https://lkml.org/lkml/2021/8/2/1114 Reported-by: nix.or.die@googlemail.com Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> CC: Raul E Rangel <rrangel@chromium.org> Fixes: d62bd5ce12d7 ("pinctrl: amd: Implement irq_set_wake") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20210809201513.12367-1-mario.limonciello@amd.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1ca46d3e |
|
12-May-2021 |
Maximilian Luz <luzmaximilian@gmail.com> |
pinctrl/amd: Add device HID for new AMD GPIO controller Add device HID AMDI0031 to the AMD GPIO controller driver match table. This controller can be found on Microsoft Surface Laptop 4 devices and seems similar enough that we can just copy the existing AMDI0030 entry. Cc: <stable@vger.kernel.org> # 5.10+ Tested-by: Sachi King <nakato@nakato.io> Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20210512210316.1982416-1-luzmaximilian@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d62bd5ce |
|
29-Apr-2021 |
Raul E Rangel <rrangel@chromium.org> |
pinctrl: amd: Implement irq_set_wake This allows the OS to control which devices produce wake events. $ grep enabled /sys/kernel/irq/*/wakeup /sys/kernel/irq/24/wakeup:enabled Signed-off-by: Raul E Rangel <rrangel@chromium.org> Link: https://lore.kernel.org/r/20210429163341.1.I7631534622233689dd81410525e0dd617b9b2012@changeid Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
47a00014 |
|
25-Nov-2020 |
Coiby Xu <coiby.xu@gmail.com> |
pinctrl: amd: remove debounce filter setting in IRQ type setting Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). Together with commit 06abe8291bc31839950f7d0362d9979edc88a666 ("pinctrl: amd: fix incorrect way to disable debounce filter") and Andy's patch "gpiolib: acpi: Take into account debounce settings" [1], this will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000), Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [2][3] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/ 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") [2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39cc1d33 |
|
05-Nov-2020 |
Coiby Xu <coiby.xu@gmail.com> |
pinctrl: amd: print debounce filter info in debugfs Print the status of debounce filter as follows, $ cat /sys/kernel/debug/gpio pin129 interrupt is disabled | interrupt is masked | disable wakeup in S0i3 state | disable wakeup in S3 state | disable wakeup in S4/S5 state| input is high | pull-up is disabled | Pull-down is disabled | output is disabled | debouncing filter disabled | 0x50000 pin130 interrupt is disabled | interrupt is masked | disable wakeup in S0i3 state | disable wakeup in S3 state | disable wakeup in S4/S5 state | input is high | pull-up is disabled | Pull-down is disabled | output is disabled | debouncing filter (high) enabled | debouncing timeout is 124800 (us)| 0x503c8 Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Link: https://lore.kernel.org/r/20201105231912.69527-4-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c64a6a0d |
|
05-Nov-2020 |
Coiby Xu <coiby.xu@gmail.com> |
pinctrl: amd: use higher precision for 512 RtcClk RTC is 32.768kHz thus 512 RtcClk equals 15625 usec. The documentation likely has dropped precision and that's why the driver mistakenly took the slightly deviated value. Cc: stable@vger.kernel.org Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/linux-gpio/2f4706a1-502f-75f0-9596-cc25b4933b6c@redhat.com/ Link: https://lore.kernel.org/r/20201105231912.69527-3-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
06abe829 |
|
05-Nov-2020 |
Coiby Xu <coiby.xu@gmail.com> |
pinctrl: amd: fix incorrect way to disable debounce filter The correct way to disable debounce filter is to clear bit 5 and 6 of the register. Cc: stable@vger.kerne.org Signed-off-by: Coiby Xu <coiby.xu@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/linux-gpio/df2c008b-e7b5-4fdd-42ea-4d1c62b52139@redhat.com/ Link: https://lore.kernel.org/r/20201105231912.69527-2-coiby.xu@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e81376eb |
|
21-Jul-2020 |
Linus Walleij <linus.walleij@linaro.org> |
pinctrl: amd: Use irqchip template This makes the driver use the irqchip template to assign properties to the gpio_irq_chip instead of using the explicit call to gpiochip_irqchip_add(). The irqchip is instead added while adding the gpiochip. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Cc: Sandeep Singh <sandeep.singh@amd.com> Link: https://lore.kernel.org/r/20200722101545.144373-1-linus.walleij@linaro.org
|
#
de4334f7 |
|
13-Jul-2020 |
Lee Jones <lee.jones@linaro.org> |
pinctrl: pinctrl-amd: Do not define 'struct acpi_device_id' when !CONFIG_ACPI Since ACPI_PTR() is used to NULLify the value when !CONFIG_ACPI, 'struct amd_gpio_acpi_match' becomes defined but unused. Fixes the following W=1 kernel build warning(s): drivers/pinctrl/pinctrl-amd.c:959:36: warning: ‘amd_gpio_acpi_match’ defined but not used [-Wunused-const-variable=] 959 | static const struct acpi_device_id amd_gpio_acpi_match[] = { Signed-off-by: Lee Jones <lee.jones@linaro.org> Cc: Ken Xue <Ken.Xue@amd.com> Cc: "Wu, Jeff" <Jeff.Wu@amd.com> Cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Cc: Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20200713144930.1034632-26-lee.jones@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5f4962dd |
|
26-Jun-2020 |
Furquan Shaikh <furquan@google.com> |
pinctrl: amd: Honor IRQ trigger type requested by the caller This change drops the override in `amd_gpio_irq_set_type()` that ignores the IRQ trigger type settings from the caller. The device driver (caller) is in a better position to identify the right trigger type for the device based on the usage as well as the information exposed by the BIOS. There are instances where the device driver might want to configure the trigger type differently in different modes. An example of this is gpio-keys driver which configures IRQ type as trigger on both edges (to identify assert and deassert events) when in S0 and reconfigures the trigger type using the information provided by the BIOS when going into suspend to ensure that the wake happens on the required edge. This override in `amd_gpio_irq_set_type()` prevents the caller from being able to reconfigure trigger type once it is set either based on ACPI information or the type used by the first caller for IRQ on a given GPIO line. Without this change, pen-insert gpio key (used by garaged stylus on a Chromebook) works fine in S0 (i.e. insert and eject events are correctly identified), however, BIOS configuration for wake on only pen eject i.e. only-rising edge or only-falling edge is not honored. With this change, it was verified that pen-insert gpio key behavior is correct in both S0 and for wakeup from S3. Signed-off-by: Furquan Shaikh <furquan@google.com> Signed-off-by: Shyam Sundar S K<Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20200626211026.513520-1-furquan@google.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3c827873 |
|
14-Feb-2020 |
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> |
pinctrl: Use new GPIO_LINE_DIRECTION Use newly added GPIO defines GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT instead of using hard-coded 1 and 0. Main benefit is to make it easier to see which values mean IN and which OUT. As a side effect this helps GPIO framework to change the direction defines to something else if ever needed. Please note that return value from get_direction call on pinctrl-axp209 driver was changed. Previously pinctrl-axp209 might have returned value 2 for direction INPUT. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Link: https://lore.kernel.org/r/20200214135712.GA14557@localhost.localdomain Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4bdc0d67 |
|
06-Jan-2020 |
Christoph Hellwig <hch@lst.de> |
remove ioremap_nocache and devm_ioremap_nocache ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
|
#
10ff58aa |
|
22-Oct-2019 |
Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> |
pinctrl: amd: fix __iomem annotation in amd_gpio_irq_handler() The regs pointer in amd_gpio_irq_handler() should have __iomem on it, so add that to fix the following sparse warnings: drivers/pinctrl/pinctrl-amd.c:555:14: warning: incorrect type in assignment (different address spaces) drivers/pinctrl/pinctrl-amd.c:555:14: expected unsigned int [usertype] *regs drivers/pinctrl/pinctrl-amd.c:555:14: got void [noderef] <asn:2> *base drivers/pinctrl/pinctrl-amd.c:563:34: warning: incorrect type in argument 1 (different address spaces) drivers/pinctrl/pinctrl-amd.c:563:34: expected void const volatile [noderef] <asn:2> *addr drivers/pinctrl/pinctrl-amd.c:563:34: got unsigned int [usertype] * drivers/pinctrl/pinctrl-amd.c:580:34: warning: incorrect type in argument 1 (different address spaces) drivers/pinctrl/pinctrl-amd.c:580:34: expected void const volatile [noderef] <asn:2> *addr drivers/pinctrl/pinctrl-amd.c:580:34: got unsigned int [usertype] * drivers/pinctrl/pinctrl-amd.c:587:25: warning: incorrect type in argument 2 (different address spaces) drivers/pinctrl/pinctrl-amd.c:587:25: expected void volatile [noderef] <asn:2> *addr drivers/pinctrl/pinctrl-amd.c:587:25: got unsigned int [usertype] * Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Link: https://lore.kernel.org/r/20191022151154.5986-1-ben.dooks@codethink.co.uk Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d21b8adb |
|
14-Aug-2019 |
Daniel Drake <drake@endlessm.com> |
pinctrl: amd: disable spurious-firing GPIO IRQs When cold-booting Asus X434DA, GPIO 7 is found to be already configured as an interrupt, and the GPIO level is found to be in a state that causes the interrupt to fire. As soon as pinctrl-amd probes, this interrupt fires and invokes amd_gpio_irq_handler(). The IRQ is acked, but no GPIO-IRQ handler was invoked, so the GPIO level being unchanged just causes another interrupt to fire again immediately after. This results in an interrupt storm causing this platform to hang during boot, right after pinctrl-amd is probed. Detect this situation and disable the GPIO interrupt when this happens. This enables the affected platform to boot as normal. GPIO 7 actually is the I2C touchpad interrupt line, and later on, i2c-multitouch loads and re-enables this interrupt when it is ready to handle it. Instead of this approach, I considered disabling all GPIO interrupts at probe time, however that seems a little risky, and I also confirmed that Windows does not seem to have this behaviour: the same 41 GPIO IRQs are enabled under both Linux and Windows, which is a far larger collection than the GPIOs referenced by the DSDT on this platform. Signed-off-by: Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/r/20190814090540.7152-1-drake@endlessm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
64c4dcbf |
|
30-Jul-2019 |
Stephen Boyd <swboyd@chromium.org> |
pinctrl: Remove dev_err() usage after platform_get_irq() We don't need dev_err() messages when platform_get_irq() fails now that platform_get_irq() prints an error message itself when something goes wrong. Let's remove these prints with a simple semantic patch. // <smpl> @@ expression ret; struct platform_device *E; @@ ret = ( platform_get_irq(E, ...) | platform_get_irq_byname(E, ...) ); if ( \( ret < 0 \| ret <= 0 \) ) { ( -if (ret != -EPROBE_DEFER) -{ ... -dev_err(...); -... } | ... -dev_err(...); ) ... } // </smpl> While we're here, remove braces on if statements that only have one statement (manually). Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20190730181557.90391-34-swboyd@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
75a6faf6 |
|
01-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 422 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 101 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190531190113.822954939@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
279ffafa |
|
04-Apr-2019 |
Sandeep Singh <sandeep.singh@amd.com> |
pinctrl: Added IRQF_SHARED flag for amd-pinctrl driver Some of the AMD reference boards used single GPIO line for multiple devices. So added IRQF_SHARED flag in amd pinctrl driver. Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
48c67f1f |
|
04-Jan-2019 |
Matteo Croce <mcroce@redhat.com> |
pinctrl/amd: fix typo Fix spelling mistake: "lenght" -> "length" Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9f540c3e |
|
21-Oct-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
pinctrl: pinctrl-amd: simplify getting .driver_data 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 <wsa+renesas@sang-engineering.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b85bfa24 |
|
22-Sep-2018 |
Daniel Kurtz <djkurtz@chromium.org> |
pinctrl/amd: poll InterruptEnable bits in amd_gpio_irq_set_type 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 <djkurtz@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1c5fb66a |
|
13-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
pinctrl: Include <linux/gpio/driver.h> nothing else These drivers are GPIO drivers, and the do not need to use the legacy header in <linux/gpio.h>, go directly for <linux/gpio/driver.h> 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 <linus.walleij@linaro.org>
|
#
8bbed1ee |
|
16-Jul-2018 |
Daniel Kurtz <djkurtz@chromium.org> |
pinctrl/amd: only handle irq if it is pending and unmasked 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 <djkurtz@chromium.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1766e4b7 |
|
16-Jul-2018 |
Daniel Kurtz <djkurtz@chromium.org> |
pinctrl/amd: fix gpio irq level in debugfs 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 <djkurtz@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4c1de041 |
|
12-Mar-2018 |
Daniel Kurtz <djkurtz@chromium.org> |
pinctrl/amd: poll InterruptEnable bits in enable_irq 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 <djkurtz@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
12b10f47 |
|
16-Feb-2018 |
Daniel Kurtz <djkurtz@chromium.org> |
pinctrl/amd: add get_direction handler 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 <djkurtz@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f0fbe7bc |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irqdomain into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6afb1026 |
|
01-Oct-2017 |
Daniel Drake <drake@endlessm.com> |
pinctrl/amd: fix masking of GPIO interrupts On Asus laptop models X505BA, X505BP, X542BA and X542BP, the i2c-hid touchpad (using a GPIO for interrupts) becomes unresponsive after a few minutes of usage, or after placing two fingers on the touchpad, which seems to have the effect of queuing up a large amount of input data to be transferred. When the touchpad is in unresponsive state, we observed that the GPIO level-triggered interrupt is still at it's active level, however the pinctrl-amd driver is not receiving/dispatching more interrupts at this point. After the initial interrupt arrives, amd_gpio_irq_mask() is called however we then see amd_gpio_irq_handler() being called repeatedly for the same irq; the interrupt mask is not taking effect because of the following sequence of events: - amd_gpio_irq_handler fires, reads and caches pin reg - amd_gpio_irq_handler calls generic_handle_irq() - During IRQ handling, amd_gpio_irq_mask() is called and modifies pin reg - amd_gpio_irq_handler clears interrupt by writing cached value The stale cached value written at the final stage undoes the masking. Fix this by re-reading the register before clearing the interrupt. I also spotted that the interrupt-clearing code can race against amd_gpio_irq_mask() / amd_gpio_irq_unmask(), so add locking there. Presumably this race was leading to the loss of interrupts. After these changes, the touchpad appears to be working fine. Signed-off-by: Daniel Drake <drake@endlessm.com> Acked-by: Shah, Nehal-bakulchandra <Nehal-Bakulchandra.shah@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2d71dfa2 |
|
13-Sep-2017 |
Colin Ian King <colin.king@canonical.com> |
pinctrl/amd: make functions amd_gpio_suspend and amd_gpio_resume static The functions amd_gpio_suspend and amd_gpio_resume are local to the source and do not need to be in global scope, so make them static. Cleans up sparse warnings: symbol 'amd_gpio_suspend' was not declared. Should it be static? symbol 'amd_gpio_resume' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79d2c8be |
|
11-Sep-2017 |
Daniel Drake <drake@endlessm.com> |
pinctrl/amd: save pin registers over suspend/resume The touchpad in the Asus laptop models X505BA/BP and X542BA/BP is unresponsive after suspend/resume. The following error appears during resume: i2c_hid i2c-ELAN1300:00: failed to reset device. The problem here is that i2c_hid does not notice the interrupt being generated at this point, because the GPIO is no longer configured for interrupts. Fix this by saving pinctrl-amd pin registers during suspend and restoring them at resume time. Based on code from pinctrl-intel. Cc: stable@vger.kernel.org Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2e6424ab |
|
09-Aug-2017 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
pinctrl: amd: fix error return code in amd_gpio_probe() platform_get_irq() returns an error code, but the pinctrl-amd driver ignores it and always returns -EINVAL. This is not correct and, prevents -EPROBE_DEFER from being propagated properly. Print and propagate the return value of platform_get_irq on failure. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ba714a9c |
|
23-May-2017 |
Thomas Gleixner <tglx@linutronix.de> |
pinctrl/amd: Use regular interrupt instead of chained The AMD pinctrl driver uses a chained interrupt to demultiplex the GPIO interrupts. Kevin Vandeventer reported, that his new AMD Ryzen locks up hard on boot when the AMD pinctrl driver is initialized. The reason is an interrupt storm. It's not clear whether that's caused by hardware or firmware or both. Using chained interrupts on X86 is a dangerous endavour. If a system is misconfigured or the hardware buggy there is no safety net to catch an interrupt storm. Convert the driver to use a regular interrupt for the demultiplex handler. This allows the interrupt storm detector to catch the malfunction and lets the system boot up. This should be backported to stable because it's likely that more users run into this problem as the AMD Ryzen machines are spreading. Reported-by: Kevin Vandeventer Link: https://bugzilla.suse.com/show_bug.cgi?id=1034261 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
add7bfce |
|
03-May-2017 |
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> |
pinctrl/amd: Update contact information for AMD pinctrl/amd Updating the point of contact for AMD GPIO driver. Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Cc: Ken Xue <Ken.Xue@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0a95160e |
|
23-Nov-2016 |
Masanari Iida <standby24x7@gmail.com> |
treewide: Fix typos in printk This patch fix some spelling typos found in printk. [jkosina@suse.cz: drop arch/arm64/kernel/hibernate.c that was already in place] Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
229710fe |
|
09-Mar-2017 |
Julia Cartwright <julia@ni.com> |
pinctrl: amd: make use of raw_spinlock variants The amd pinctrl drivers currently implement an irq_chip for handling interrupts; due to how irq_chip handling is done, it's necessary for the irq_chip methods to be invoked from hardirq context, even on a a real-time kernel. Because the spinlock_t type becomes a "sleeping" spinlock w/ RT kernels, it is not suitable to be used with irq_chips. A quick audit of the operations under the lock reveal that they do only minimal, bounded work, and are therefore safe to do under a raw spinlock. Signed-off-by: Julia Cartwright <julia@ni.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2956b5d9 |
|
23-Jan-2017 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8dca4a41 |
|
17-Jan-2017 |
Wei Yongjun <weiyongjun1@huawei.com> |
pinctrl/amd: Drop pinctrl_unregister for devm_ registered device It's not necessary to unregister pin controller device registered with devm_pinctrl_register() and using pinctrl_unregister() leads to a double free. Fixes: 3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
581d3c20 |
|
11-Jan-2017 |
Arnd Bergmann <arnd@arndb.de> |
pinctrl: amd: avoid maybe-uninitalized warning Since gpio_dev->hwbank_num is now a variable, the compiler cannot figure out if pin_num is initialized at all: drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show': drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized] for (; i < pin_num; i++) { ^~~ drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized] This adds a 'default' statement to make that case well-defined. Fixes: 3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3775dac1 |
|
06-Jan-2017 |
Dan Carpenter <dan.carpenter@oracle.com> |
pinctrl/amd: white space cleanups in amd_gpio_dbg_show() We accidentally deleted two tabs from the first line, but even with that fixed the conditions were not really kernel style. Put the && at the end of the line so we can align the condition clauses. Also add spaces around the "+" operator. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6ac4c1ad |
|
03-Jan-2017 |
Linus Walleij <linus.walleij@linaro.org> |
pinctrl: amd: fix compilation warning 3bfd44306c65 ("pinctrl: amd: Add support for additional GPIO") created the following warning: drivers/pinctrl/pinctrl-amd.c: In function 'amd_gpio_dbg_show': drivers/pinctrl/pinctrl-amd.c:210:3: warning: 'pin_num' may be used uninitialized in this function [-Wmaybe-uninitialized] for (; i < pin_num; i++) { ^ drivers/pinctrl/pinctrl-amd.c:172:21: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized] unsigned int bank, i, pin_num; ^ Fix this by adding a guarding default case for illegal bank numbers. Cc: S-k Shyam-sundar <Shyam-sundar.S-k@amd.com> Cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2983f296 |
|
08-Dec-2016 |
Shyam Sundar S K <ssundark@amd.com> |
pinctrl/amd: Set the level based on ACPI tables In the function amd_gpio_irq_set_type, read the values from the ACPI table to set the level and drop the settings passed by the client. Cc: <stable@vger.kernel.org> # 4.8.x+ Reviewed-by: Pankaj Sen <Pankaj.Sen@amd.com> Reviewed-by: Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> Reviewed-by: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com> Signed-off-by: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3bfd4430 |
|
05-Dec-2016 |
Shah, Nehal-bakulchandra <Nehal-Bakulchandra.shah@amd.com> |
pinctrl: amd: Add support for additional GPIO This patch adds support for new Bank and adds IRQCHIP_SKIP_SET_WAKE flag. Reviewed-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com> Signed-off-by: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e084448b |
|
09-Sep-2016 |
Agrawal, Nitesh-kumar <Nitesh-kumar.Agrawal@amd.com> |
pinctrl/amd: switch to using a bool for level The earlier patch can be simplified by using a bool to indicate level trigger. Reviewed-by: Pankaj Sen <Pankaj.Sen@amd.com> Signed-off-by: Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> [Fixup to earlier manually applied patch] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
499c7196 |
|
31-Aug-2016 |
Agrawal, Nitesh-kumar <Nitesh-kumar.Agrawal@amd.com> |
pinctrl/amd: Configure GPIO register using BIOS settings In the function amd_gpio_irq_set_type, use the settings provided by the BIOS,when the LevelTrig is Edge and activeLevel is HIGH, to configure the GPIO registers. Ignore the settings from client. Reviewed-by: Pankaj Sen <Pankaj.Sen@amd.com> Signed-off-by:Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8cf43455 |
|
26-Jul-2016 |
Agrawal, Nitesh-kumar <Nitesh-kumar.Agrawal@amd.com> |
pinctrl/amd: Remove the default de-bounce time In the function amd_gpio_irq_enable() and amd_gpio_direction_input(), remove the code which is setting the default de-bounce time to 2.75ms. The driver code shall use the same settings as specified in BIOS. Any default assignment impacts TouchPad behaviour when the LevelTrig is set to EDGE FALLING. Cc: stable@vger.kernel.org Reviewed-by: Ken Xue <Ken.Xue@amd.com> Signed-off-by: Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b9416498 |
|
18-Jul-2016 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
Revert "pinctrl: amd: make it explicitly non-modular" This reverts commit b8c2b10a9bc0272a20e096852f8fbbf361749dda. This patch was in my queue at the same time that a conversion of the same driver from bool --> tristate was pending and merged. That is commit 337ea0fb1535 ("pinctrl: Turn AMD support to tristate") Normally the conflict would show up in the build coverage I do, however in this case an avoidable instance of linux/module.h in linux/gpio/driver.h (!) causes the build failure to be masked and instead the tristate gets built-in even for selected "=m". In working on removing module.h from driver.h this issue was then revealed (along with other implicit module.h assumptions in gpio, and mfd -- which will be fixed separately.) Cc: linux-gpio@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b8c2b10a |
|
06-Jun-2016 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
pinctrl: amd: make it explicitly non-modular The Kconfig currently controlling compilation of this code is: config PINCTRL_AMD bool "AMD GPIO pin control" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. We explicitly disallow a driver unbind, since that doesn't have a sensible use case anyway, and it allows us to drop the ".remove" code for non-modular drivers. Since module_platform_driver() uses the same init level priority as builtin_platform_driver() the init ordering remains unchanged with this commit. Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Cc: Ken Xue <Ken.Xue@amd.com> Cc: Jeff Wu <Jeff.Wu@amd.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
251e22ab |
|
24-Feb-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
pinctrl: amd: Use devm_pinctrl_register() for pinctrl registration Use devm_pinctrl_register() for pin control registration and clean error path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d32f7fd3 |
|
31-Mar-2016 |
Irina Tirdea <irina.tirdea@intel.com> |
pinctrl: Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map, since it does not depend on device tree despite the current name. This will enforce a consistent naming in pinctr-utils.c and will make it clear it can be called from outside device tree (e.g. from ACPI handling code). Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
42a44402 |
|
10-Mar-2016 |
Wang Hongcheng <annie.wang@amd.com> |
pinctrl: amd:Add device HID for future AMD GPIO controller Add device HID AMDI0030 to match the AMD ACPI Vendor ID (AMDI) as registered in http://www.uefi.org/acpi_id_list, and the GPIO controller on future AMD paltform will use the HID instead of AMD0030. Signed-off-by: Wang Hongcheng <annie.wang@amd.com> Acked-by: Ken Xue <ken.Xue@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
424a6c60 |
|
06-Feb-2016 |
Wei Yongjun <yongjun_wei@trendmicro.com.cn> |
pinctrl: Fix return value check in amd_gpio_probe() In case of error, the function devm_ioremap_nocache() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
04d36723 |
|
08-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
pinctrl: amd: use gpiochip data pointer This makes the driver use the data pointer added to the gpio_chip to store a pointer to the state container instead of relying on container_of(). Cc: Ken Xue <Ken.Xue@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
58383c78 |
|
04-Nov-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: change member .dev to .parent The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bd0b9ac4 |
|
14-Sep-2015 |
Thomas Gleixner <tglx@linutronix.de> |
genirq: Remove irq argument from irq flow handlers Most interrupt flow handlers do not use the irq argument. Those few which use it can retrieve the irq number from the irq descriptor. Remove the argument. Search and replace was done with coccinelle and some extra helper scripts around it. Thanks to Julia for her help! Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Jiang Liu <jiang.liu@linux.intel.com>
|
#
fa00fecc |
|
12-Jul-2015 |
Thomas Gleixner <tglx@linutronix.de> |
pinctrl/amd: Prepare amd_gpio_irq_handler for irq argument removal The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org>
|
#
5663bb27 |
|
03-Jun-2015 |
Jiang Liu <jiang.liu@linux.intel.com> |
pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
9d829314 |
|
23-Jun-2015 |
Thomas Gleixner <tglx@linutronix.de> |
pinctrl/amd: Use irq_set_handler_locked() Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Julia Lawall <julia.lawall@lip6.fr> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org
|
#
323de9ef |
|
08-Jun-2015 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
pinctrl: make pinctrl_register() return proper error code Currently, pinctrl_register() just returns NULL on error, so the callers can not know the exact reason of the failure. Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some -ENOMEM on error of pinctrl_register(), although the error code might be different from the real cause of the error. This commit reworks pinctrl_register() to return the appropriate error code and modifies all of the pinctrl drivers to use IS_ERR() for the error checking and PTR_ERR() for getting the error code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Patrice Chotard <patrice.chotard@st.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Lee Jones <lee@kernel.org> Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Ray Jui <rjui@broadcom.com> Acked-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com> Acked-by: Wei Chen <Wei.Chen@csr.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3944e7b7 |
|
01-Jun-2015 |
Fabio Estevam <fabio.estevam@freescale.com> |
pinctrl: Remove .owner field platform_driver does not need to set the owner field, as it will be populated by the driver core, so just remove it. The semantic patch that makes this change is available in scripts/coccinelle/api/platform_no_drv_owner.cocci. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
25a853d0 |
|
27-Mar-2015 |
Ken Xue <Ken.Xue@amd.com> |
Fix inconsistent spinlock of AMD GPIO driver which can be recognized by static analysis tool smatch. Declare constant Variables with Sparse's suggestion. Signed-off-by: Ken Xue <Ken.Xue@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dbad75dd |
|
10-Mar-2015 |
Ken Xue <Ken.Xue@amd.com> |
pinctrl: add AMD GPIO driver support. KERNCZ GPIO is a new IP from AMD. it can be implemented in both x86 and ARM. Current driver patch only support GPIO in x86. Signed-off-by: Ken Xue <Ken.Xue@amd.com> [Moved back to <linux/gpio.h> header] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|