* Re: [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains
From: Linus Walleij @ 2019-08-23 10:13 UTC (permalink / raw)
To: Marc Zyngier
Cc: Brian Masney, open list:GPIO SUBSYSTEM, Bartosz Golaszewski,
Thomas Gleixner, Lina Iyer, Jon Hunter, Sowjanya Komatineni,
Bitan Biswas, linux-tegra, David Daney, Masahiro Yamada,
Thierry Reding
In-Reply-To: <63f2d086-eb71-4153-071e-71102fe24a14@arm.com>
On Fri, Aug 23, 2019 at 11:12 AM Marc Zyngier <marc.zyngier@arm.com> wrote:
> > We should be encouraged to operate on IRQ descriptors rather
> > than IRQ numbers when doing this kind of deep core work,
> > right?
>
> Certainly, I'd like to gradually move over from the IRQ number to an
> irq_desc. In interrupt-heavy contexts, this ends up being quite time
> consuming. I have an old patch series somewhere changing irq domains to
> use irq_descs internally instead of IRQ numbers, which I should maybe
> revive.
We currently interact most heavily with the irqchip by way of
mapping GPIO lines to the corresponding IRQs, so I suppose
the existing
int gpiod_to_irq(struct gpio_desc *desc);
Need a corresponding
struct irq_desc *gpiod_to_irq_desc(struct gpio_desc *desc);
at some point, and then we can start to de-pollute the kernel
from this for all drivers using the modern GPIO descriptor
API. It's a big task but can certainly be done with some
help.
On the driver back-end we are in surprisingly good shape
thanks to all the abstractions provided for dealing with IRQ
chip drivers.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: ftgpio: Fix an error handling path in 'ftgpio_gpio_probe()'
From: Linus Walleij @ 2019-08-23 10:02 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Bartosz Golaszewski, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, kernel-janitors
In-Reply-To: <20190822204538.4791-1-christophe.jaillet@wanadoo.fr>
On Thu, Aug 22, 2019 at 10:45 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> If 'devm_kcalloc()' fails, we should go through the error handling path,
> should some clean-up be needed.
>
> Fixes: 42d9fc7176eb ("gpio: ftgpio: Pass irqchip when adding gpiochip")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Patch applied, thanks!
Yours,
Linus Waleij
^ permalink raw reply
* Re: [PATCH] gpio: Move gpiochip_lock/unlock_as_irq to gpio/driver.h
From: Linus Walleij @ 2019-08-23 10:00 UTC (permalink / raw)
To: YueHaibing
Cc: Bartosz Golaszewski, Alexandre Courbot,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <20190822031817.32888-1-yuehaibing@huawei.com>
On Thu, Aug 22, 2019 at 5:19 AM YueHaibing <yuehaibing@huawei.com> wrote:
> If CONFIG_GPIOLIB is not, gpiochip_lock/unlock_as_irq will
> conflict as this:
>
> In file included from sound/soc/codecs/wm5100.c:18:0:
> ./include/linux/gpio.h:224:19: error: static declaration of gpiochip_lock_as_irq follows non-static declaration
> static inline int gpiochip_lock_as_irq(struct gpio_chip *chip,
> ^~~~~~~~~~~~~~~~~~~~
> In file included from sound/soc/codecs/wm5100.c:17:0:
> ./include/linux/gpio/driver.h:494:5: note: previous declaration of gpiochip_lock_as_irq was here
> int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
> ^~~~~~~~~~~~~~~~~~~~
> In file included from sound/soc/codecs/wm5100.c:18:0:
> ./include/linux/gpio.h:231:20: error: static declaration of gpiochip_unlock_as_irq follows non-static declaration
> static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
> ^~~~~~~~~~~~~~~~~~~~~~
> In file included from sound/soc/codecs/wm5100.c:17:0:
> ./include/linux/gpio/driver.h:495:6: note: previous declaration of gpiochip_unlock_as_irq was here
> void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
> ^~~~~~~~~~~~~~~~~~~~~~
>
> Move them to gpio/driver.h and use CONFIG_GPIOLIB guard this.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: d74be6dfea1b ("gpio: remove gpiod_lock/unlock_as_irq()")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied with some fuzzing.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: meson: meson: Add of_node_put() before return
From: Linus Walleij @ 2019-08-23 9:48 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: Kevin Hilman, Linux ARM, open list:GPIO SUBSYSTEM,
open list:ARM/Amlogic Meson...
In-Reply-To: <20190815060718.3286-1-nishkadg.linux@gmail.com>
On Thu, Aug 15, 2019 at 8:07 AM Nishka Dasgupta
<nishkadg.linux@gmail.com> wrote:
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Patch applied with Neil's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] microblaze: Switch to standard restart handler
From: Linus Walleij @ 2019-08-23 9:47 UTC (permalink / raw)
To: linux-gpio
Cc: Bartosz Golaszewski, Linus Walleij, Arnd Bergmann, Michal Simek
The microblaze uses the legacy APIs to dig out a GPIO pin
defined in the root of the device tree to issue a hard
reset of the platform.
Asserting a hard reset should be done using the standard
DT-enabled and fully GPIO descriptor aware driver in
drivers/power/reset/gpio-restart.c using the bindings
from Documentation/devicetree/bindings/power/reset/gpio-restart.txt
To achieve this, first make sure microblaze makes use of
the standard kernel restart path utilizing do_kernel_restart()
from <linux/reboot.h>. Put in some grace time and an
emergency print if the restart does not properly assert.
As this is basic platform functionality we patch the DTS
file and defconfig in one go for a lockstep change.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Simek <monstr@monstr.eu>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Fix the reset GPIOs property in the DTS file to be
just "gpios" as expected by the driver.
Hi Michal, would be great if you could test and fix this up
so I can get rid of one more site where legacy GPIO is used.
I am unsure of the appropriate polarity and delays, hence the
comments in the DTS file.
---
arch/microblaze/boot/dts/system.dts | 16 +++++-
arch/microblaze/configs/mmu_defconfig | 2 +
arch/microblaze/configs/nommu_defconfig | 2 +
arch/microblaze/include/asm/setup.h | 1 -
arch/microblaze/kernel/reset.c | 76 -------------------------
arch/microblaze/mm/init.c | 11 ++++
6 files changed, 30 insertions(+), 78 deletions(-)
diff --git a/arch/microblaze/boot/dts/system.dts b/arch/microblaze/boot/dts/system.dts
index 5a8a9d090c37..5b236527176e 100644
--- a/arch/microblaze/boot/dts/system.dts
+++ b/arch/microblaze/boot/dts/system.dts
@@ -18,7 +18,6 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,microblaze";
- hard-reset-gpios = <&LEDs_8Bit 2 1>;
model = "testing";
DDR2_SDRAM: memory@90000000 {
device_type = "memory";
@@ -281,6 +280,21 @@
gpios = <&LEDs_8Bit 7 1>;
};
} ;
+
+ gpio-restart {
+ compatible = "gpio-restart";
+ /*
+ * FIXME: is this active low or active high?
+ * the current flag (1) indicates active low.
+ * delay measures are templates, should be adjusted
+ * to datasheet or trial-and-error with real hardware.
+ */
+ gpios = <&LEDs_8Bit 2 1>;
+ active-delay = <100>;
+ inactive-delay = <10>;
+ wait-delay = <100>;
+ };
+
RS232_Uart_1: serial@84000000 {
clock-frequency = <125000000>;
compatible = "xlnx,xps-uartlite-1.00.a";
diff --git a/arch/microblaze/configs/mmu_defconfig b/arch/microblaze/configs/mmu_defconfig
index 92fd4e95b488..ae8d7d407ff4 100644
--- a/arch/microblaze/configs/mmu_defconfig
+++ b/arch/microblaze/configs/mmu_defconfig
@@ -59,6 +59,8 @@ CONFIG_SPI_XILINX=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_XILINX=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_XILINX_WATCHDOG=y
diff --git a/arch/microblaze/configs/nommu_defconfig b/arch/microblaze/configs/nommu_defconfig
index 06d69a6e192d..a2a6be511551 100644
--- a/arch/microblaze/configs/nommu_defconfig
+++ b/arch/microblaze/configs/nommu_defconfig
@@ -62,6 +62,8 @@ CONFIG_SPI_XILINX=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_XILINX=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_XILINX_WATCHDOG=y
diff --git a/arch/microblaze/include/asm/setup.h b/arch/microblaze/include/asm/setup.h
index ce9b7b786156..54d634ed98e6 100644
--- a/arch/microblaze/include/asm/setup.h
+++ b/arch/microblaze/include/asm/setup.h
@@ -29,7 +29,6 @@ void machine_early_init(const char *cmdline, unsigned int ram,
unsigned int fdt, unsigned int msr, unsigned int tlb0,
unsigned int tlb1);
-void machine_restart(char *cmd);
void machine_shutdown(void);
void machine_halt(void);
void machine_power_off(void);
diff --git a/arch/microblaze/kernel/reset.c b/arch/microblaze/kernel/reset.c
index fcbe1daf6316..b56af4eb91bf 100644
--- a/arch/microblaze/kernel/reset.c
+++ b/arch/microblaze/kernel/reset.c
@@ -10,82 +10,6 @@
#include <linux/init.h>
#include <linux/of_platform.h>
-/* Trigger specific functions */
-#ifdef CONFIG_GPIOLIB
-
-#include <linux/of_gpio.h>
-
-static int handle; /* reset pin handle */
-static unsigned int reset_val;
-
-static int of_platform_reset_gpio_probe(void)
-{
- int ret;
- handle = of_get_named_gpio(of_find_node_by_path("/"),
- "hard-reset-gpios", 0);
-
- if (!gpio_is_valid(handle)) {
- pr_info("Skipping unavailable RESET gpio %d (%s)\n",
- handle, "reset");
- return -ENODEV;
- }
-
- ret = gpio_request(handle, "reset");
- if (ret < 0) {
- pr_info("GPIO pin is already allocated\n");
- return ret;
- }
-
- /* get current setup value */
- reset_val = gpio_get_value(handle);
- /* FIXME maybe worth to perform any action */
- pr_debug("Reset: Gpio output state: 0x%x\n", reset_val);
-
- /* Setup GPIO as output */
- ret = gpio_direction_output(handle, 0);
- if (ret < 0)
- goto err;
-
- /* Setup output direction */
- gpio_set_value(handle, 0);
-
- pr_info("RESET: Registered gpio device: %d, current val: %d\n",
- handle, reset_val);
- return 0;
-err:
- gpio_free(handle);
- return ret;
-}
-device_initcall(of_platform_reset_gpio_probe);
-
-
-static void gpio_system_reset(void)
-{
- if (gpio_is_valid(handle))
- gpio_set_value(handle, 1 - reset_val);
- else
- pr_notice("Reset GPIO unavailable - halting!\n");
-}
-#else
-static void gpio_system_reset(void)
-{
- pr_notice("No reset GPIO present - halting!\n");
-}
-
-void of_platform_reset_gpio_probe(void)
-{
- return;
-}
-#endif
-
-void machine_restart(char *cmd)
-{
- pr_notice("Machine restart...\n");
- gpio_system_reset();
- while (1)
- ;
-}
-
void machine_shutdown(void)
{
pr_notice("Machine shutdown...\n");
diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
index a015a951c8b7..4a45e037107f 100644
--- a/arch/microblaze/mm/init.c
+++ b/arch/microblaze/mm/init.c
@@ -17,6 +17,8 @@
#include <linux/slab.h>
#include <linux/swap.h>
#include <linux/export.h>
+#include <linux/delay.h>
+#include <linux/reboot.h>
#include <asm/page.h>
#include <asm/mmu_context.h>
@@ -265,6 +267,15 @@ static void __init mmu_init_hw(void)
: : : "r11");
}
+void machine_restart(char *cmd)
+{
+ do_kernel_restart(cmd);
+ /* Give the restart hook 1 s to take us down */
+ mdelay(1000);
+ pr_emerg("Reboot failed -- System halted\n");
+ while (1);
+}
+
/*
* MMU_init sets up the basic memory mappings for the kernel,
* including both RAM and possibly some I/O regions,
--
2.21.0
^ permalink raw reply related
* Re: [v8 1/1] gpio: aspeed: Add SGPIO driver
From: Linus Walleij @ 2019-08-23 9:41 UTC (permalink / raw)
To: Hongwei Zhang
Cc: Andrew Jeffery, open list:GPIO SUBSYSTEM, Joel Stanley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-aspeed, Bartosz Golaszewski, Rob Herring,
linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <1566335128-31498-2-git-send-email-hongweiz@ami.com>
On Tue, Aug 20, 2019 at 11:05 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
This v8 patch applied for v5.4, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* Re: Status of Subsystems - MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
From: Nicolas.Ferre @ 2019-08-23 9:13 UTC (permalink / raw)
To: sebastian.duda
Cc: linux-gpio, linux-kernel, linux-arm-kernel, lukas.bulwahn,
Ludovic.Desroches, alexandre.belloni
In-Reply-To: <d2bdb45a-3571-5989-8278-6f5c7d9839f2@fau.de>
Sebastian,
On 20/08/2019 at 15:27, Sebastian Duda wrote:
> Hello Andrei,
>
> in my master thesis, I'm using the association of subsystems to
> maintainers/reviewers and its status given in the MAINTAINERS file.
> During the research I noticed that there are several subsystems without
> a status in the maintainers file. One of them is the subsystem
> `MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO` where you're mentioned as
> maintainer.
>
> Is it intended not to mention a status for your subsystems?
> What is the current status of your subsystem?
I've just removed this entry and merged it with other gpio/pinctrl
driver's entry:
https://lore.kernel.org/linux-arm-kernel/20190823083158.2649-1-nicolas.ferre@microchip.com/
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains
From: Marc Zyngier @ 2019-08-23 9:12 UTC (permalink / raw)
To: Linus Walleij, Brian Masney
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Thomas Gleixner,
Lina Iyer, Jon Hunter, Sowjanya Komatineni, Bitan Biswas,
linux-tegra, David Daney, Masahiro Yamada, Thierry Reding
In-Reply-To: <CACRpkdbZSJ4ggprUXaBJ07Hz=eryuy5=AmYOigTUmO9z4yahfQ@mail.gmail.com>
On 23/08/2019 09:24, Linus Walleij wrote:
> Hi Brian,
>
> I tried to look into this ssbi-gpio problem...
>
> Paging in Marc Z as well.
>
> On Fri, Aug 16, 2019 at 3:10 AM Brian Masney <masneyb@onstation.org> wrote:
>
>> I started to convert ssbi-gpio over to this and pm8xxx_gpio_to_irq() has
>> this little snippet that's different from spmi-gpio:
>>
>> [ fwspec mapping code ]
>>
>> /*
>> * Cache the IRQ since pm8xxx_gpio_get() needs this to get determine the
>> * line level.
>> */
>> pin->irq = ret;
>>
>> Here's the relevant code in pm8xxx_gpio_get():
>>
>> if (pin->mode == PM8XXX_GPIO_MODE_OUTPUT) {
>> ret = pin->output_value;
>> } else if (pin->irq >= 0) {
>> ret = irq_get_irqchip_state(pin->irq, IRQCHIP_STATE_LINE_LEVEL, &state);
>> ...
>> }
>
> It's a bit annoying that this API (irq_get_irqchip_state()) is relying on
> the global irq numbers and the internal function using irqdesc
> __irq_get_irqchip_state() is not exported.
>
> We should be encouraged to operate on IRQ descriptors rather
> than IRQ numbers when doing this kind of deep core work,
> right?
Certainly, I'd like to gradually move over from the IRQ number to an
irq_desc. In interrupt-heavy contexts, this ends up being quite time
consuming. I have an old patch series somewhere changing irq domains to
use irq_descs internally instead of IRQ numbers, which I should maybe
revive.
As for __irq_get_irqchip_state, the main issue is that it doesn't
perform any locking on its own, so you'd have to either provide your
own, or wrap it with something else.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3] gpiolib: Take MUX usage into account
From: Linus Walleij @ 2019-08-23 9:11 UTC (permalink / raw)
To: Ramon Fried
Cc: Bartosz Golaszewski, Stefan Wahren, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org
In-Reply-To: <20190814110035.13451-1-ramon.fried@linux.intel.com>
On Wed, Aug 14, 2019 at 1:01 PM Ramon Fried <ramon.fried@linux.intel.com> wrote:
> From: Stefan Wahren <stefan.wahren@i2se.com>
>
> The user space like gpioinfo only see the GPIO usage but not the
> MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
> pin is free/safe to use. So take the MUX usage of strict pinmux controllers
> into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Tested-by: Ramon Fried <rfried.dev@gmail.com>
> Signed-off-by: Ramon Fried <rfried.dev@gmail.com>
> ---
> v3:
> * Remove the debug message and replace with comment in code.
This V3 version applied to the pinctrl tree for testing with
Stefan's ACK.
Thanks for hashing this out.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: bcm2835: Pass irqchip when adding gpiochip
From: Linus Walleij @ 2019-08-23 9:06 UTC (permalink / raw)
To: Stefan Wahren
Cc: open list:GPIO SUBSYSTEM, Eric Anholt, Bartosz Golaszewski,
Thierry Reding
In-Reply-To: <a82230ae-4f3a-2600-0bea-85c432c56d05@i2se.com>
On Fri, Aug 23, 2019 at 10:07 AM Stefan Wahren <stefan.wahren@i2se.com> wrote:
> On 23.08.19 09:46, Linus Walleij wrote:
> > On Mon, Aug 12, 2019 at 8:29 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> >> 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. The BCM2835 has multiple parents so let's
> >> exploit the new facility in the GPIO_IRQCHIP to actually
> >> deal with multiple parents.
> >>
> >> Cc: Simon Arlott <simon@arlott.org>
> >> Cc: Eric Anholt <eric@anholt.net>
> >> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> >> Cc: Thierry Reding <treding@nvidia.com>
> >> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > This patch is a bit scary because I haven't tried converting multiple
> > parents before. Any chance one of you RPi people could give it
> > a test run, so you don't have to experience testing it in linux-next?
>
> it's on my TODO list, but i didn't had the time to test it yet.
OK sorry for stressing :(
> Can you give me some test ideas?
Anything that fires IRQ on the pin controller is a good test,
I sometimes just use tools/gpio/gpio-event-mon.c (the
more elaborate version is inside libgpiod) and have some
pushbutton or wire to ground the GPIO line under test.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: Fix irqchip initialization order
From: Linus Walleij @ 2019-08-23 9:01 UTC (permalink / raw)
To: Wei Xu
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Thierry Reding,
Grygorii Strashko, Andy Shevchenko
In-Reply-To: <5D5FA478.6090707@hisilicon.com>
On Fri, Aug 23, 2019 at 10:31 AM Wei Xu <xuwei5@hisilicon.com> wrote:
> Yes, this fixes the problem and tested based on gpio/devel branch.
> So,
>
> Tested-by: Wei Xu <xuwei5@hisilicon.com>
Awesome! Thanks a lot Wei!
I'll get this to Torvalds tree ASAP.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: Fix irqchip initialization order
From: Wei Xu @ 2019-08-23 8:31 UTC (permalink / raw)
To: Linus Walleij, linux-gpio
Cc: Bartosz Golaszewski, Thierry Reding, Grygorii Strashko,
Andy Shevchenko
In-Reply-To: <20190820080527.11796-1-linus.walleij@linaro.org>
Hi Linus,
On 2019/8/20 16:05, Linus Walleij wrote:
> The new API for registering a gpio_irq_chip along with a
> gpio_chip has a different semantic ordering than the old
> API which added the irqchip explicitly after registering
> the gpio_chip.
>
> Move the calls to add the gpio_irq_chip *last* in the
> function, so that the different hooks setting up OF and
> ACPI and machine gpio_chips are called *before* we try
> to register the interrupts, preserving the elder semantic
> order.
>
> This cropped up in the PL061 driver which used to work
> fine with no special ACPI quirks, but started to misbehave
> using the new API.
>
> Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration")
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: Grygorii Strashko <grygorii.strashko@ti.com>
> Cc: Wei Xu <xuwei5@hisilicon.com>
> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
> Reported-by: Wei Xu <xuwei5@hisilicon.com>
> Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Wei: it would be great if you could test this and
> confirm if it solves your problem, so I can apply this
> for fixes.
Sorry for the late reply!
There are some issues about my mail filter.
Yes, this fixes the problem and tested based on gpio/devel branch.
So,
Tested-by: Wei Xu <xuwei5@hisilicon.com>
Thanks!
The log is as below:
estuary:/$ cat /proc/interrupts
CPU0
2: 2610 GICv3 27 Level arch_timer
4: 33 GICv3 33 Level uart-pl011
42: 0 GICv3 23 Level arm-pmu
43: 0 ARMH0061:00 3 Edge ACPI:Event
IPI0: 0 Rescheduling interrupts
IPI1: 0 Function call interrupts
IPI2: 0 CPU stop interrupts
IPI3: 0 CPU stop (for crash dump) interrupts
IPI4: 0 Timer broadcast interrupts
IPI5: 0 IRQ work interrupts
IPI6: 0 CPU wake-up interrupts
Err: 0
estuary:/$ dmesg | more
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[ 0.000000] Linux version 5.3.0-rc1-00036-gbe23e9a
(joyx@Turing-Arch-b) (gcc version 4.9.1 20140505 (prerelease)
(crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05)) #64
SMP Fri Aug 23 16:05:08 CST 2019
commit be23e9a097e55d6733eec4336c078fda93339265
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Tue Aug 20 10:05:27 2019 +0200
gpio: Fix irqchip initialization order
Best Regards,
Wei
> ---
> drivers/gpio/gpiolib.c | 30 +++++++++++++++---------------
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 80a2a2cb673b..cca749010cd0 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1373,21 +1373,13 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
> if (status)
> goto err_remove_from_list;
>
> - status = gpiochip_irqchip_init_valid_mask(chip);
> - if (status)
> - goto err_remove_from_list;
> -
> status = gpiochip_alloc_valid_mask(chip);
> if (status)
> - goto err_remove_irqchip_mask;
> -
> - status = gpiochip_add_irqchip(chip, lock_key, request_key);
> - if (status)
> - goto err_free_gpiochip_mask;
> + goto err_remove_from_list;
>
> status = of_gpiochip_add(chip);
> if (status)
> - goto err_remove_chip;
> + goto err_free_gpiochip_mask;
>
> status = gpiochip_init_valid_mask(chip);
> if (status)
> @@ -1413,6 +1405,14 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
>
> machine_gpiochip_add(chip);
>
> + status = gpiochip_irqchip_init_valid_mask(chip);
> + if (status)
> + goto err_remove_acpi_chip;
> +
> + status = gpiochip_add_irqchip(chip, lock_key, request_key);
> + if (status)
> + goto err_remove_irqchip_mask;
> +
> /*
> * By first adding the chardev, and then adding the device,
> * we get a device node entry in sysfs under
> @@ -1424,21 +1424,21 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
> if (gpiolib_initialized) {
> status = gpiochip_setup_dev(gdev);
> if (status)
> - goto err_remove_acpi_chip;
> + goto err_remove_irqchip;
> }
> return 0;
>
> +err_remove_irqchip:
> + gpiochip_irqchip_remove(chip);
> +err_remove_irqchip_mask:
> + gpiochip_irqchip_free_valid_mask(chip);
> err_remove_acpi_chip:
> acpi_gpiochip_remove(chip);
> err_remove_of_chip:
> gpiochip_free_hogs(chip);
> of_gpiochip_remove(chip);
> -err_remove_chip:
> - gpiochip_irqchip_remove(chip);
> err_free_gpiochip_mask:
> gpiochip_free_valid_mask(chip);
> -err_remove_irqchip_mask:
> - gpiochip_irqchip_free_valid_mask(chip);
> err_remove_from_list:
> spin_lock_irqsave(&gpio_lock, flags);
> list_del(&gdev->list);
^ permalink raw reply
* Re: [PATCH 1/6 v2] gpio: Add support for hierarchical IRQ domains
From: Linus Walleij @ 2019-08-23 8:24 UTC (permalink / raw)
To: Brian Masney, Marc Zyngier
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Thomas Gleixner,
Lina Iyer, Jon Hunter, Sowjanya Komatineni, Bitan Biswas,
linux-tegra, David Daney, Masahiro Yamada, Thierry Reding
In-Reply-To: <20190816011054.GA1041@onstation.org>
Hi Brian,
I tried to look into this ssbi-gpio problem...
Paging in Marc Z as well.
On Fri, Aug 16, 2019 at 3:10 AM Brian Masney <masneyb@onstation.org> wrote:
> I started to convert ssbi-gpio over to this and pm8xxx_gpio_to_irq() has
> this little snippet that's different from spmi-gpio:
>
> [ fwspec mapping code ]
>
> /*
> * Cache the IRQ since pm8xxx_gpio_get() needs this to get determine the
> * line level.
> */
> pin->irq = ret;
>
> Here's the relevant code in pm8xxx_gpio_get():
>
> if (pin->mode == PM8XXX_GPIO_MODE_OUTPUT) {
> ret = pin->output_value;
> } else if (pin->irq >= 0) {
> ret = irq_get_irqchip_state(pin->irq, IRQCHIP_STATE_LINE_LEVEL, &state);
> ...
> }
It's a bit annoying that this API (irq_get_irqchip_state()) is relying on
the global irq numbers and the internal function using irqdesc
__irq_get_irqchip_state() is not exported.
We should be encouraged to operate on IRQ descriptors rather
than IRQ numbers when doing this kind of deep core work,
right?
> What do you think about using EXPORT_SYMBOL_GPL() for gpiochip_to_irq() so
> that we can call it in pm8xxx_gpio_to_irq()?
I would like to avoid that because people tend to abuse every
API I expose (leasson learnt: APIs shall be narrow and deep).
> Or do you have any other
> suggestions for how we can get rid of that IRQ cache?
So the issue is that moving this to the hierarchical helpers
rids pm8xxx_gpio_to_irq() and we needed that to map this.
I would rather just add a new driver API to wrap the irqchip
API:
ret = gpiochip_get_irq_state(offset, IRQCHIP_STATE_LINE_LEVEL, &state);
Where int gpiochip_get_own_irq_state(int offset, ...) will figure
out the gpio_desc of the offset and then call gpiod_to_irq()
and then use that irq number to call irq_get_irqchip_state()
and the goal is met.
This should work I think, and expose a more precise
API for what this driver wants.
> I don't see any other issues for ssbi-gpio.
That's good news!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: bcm2835: Pass irqchip when adding gpiochip
From: Stefan Wahren @ 2019-08-23 8:07 UTC (permalink / raw)
To: Linus Walleij, open list:GPIO SUBSYSTEM, Eric Anholt
Cc: Bartosz Golaszewski, Thierry Reding
In-Reply-To: <CACRpkdbBaiVQ+BUNZEYNv6dGZjAbS=eA54dLTQ99Ngvbk7YQ9Q@mail.gmail.com>
Hi Linus,
[removed Simon from CC to stop annoy him]
On 23.08.19 09:46, Linus Walleij wrote:
> On Mon, Aug 12, 2019 at 8:29 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> 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. The BCM2835 has multiple parents so let's
>> exploit the new facility in the GPIO_IRQCHIP to actually
>> deal with multiple parents.
>>
>> Cc: Simon Arlott <simon@arlott.org>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Thierry Reding <treding@nvidia.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> This patch is a bit scary because I haven't tried converting multiple
> parents before. Any chance one of you RPi people could give it
> a test run, so you don't have to experience testing it in linux-next?
it's on my TODO list, but i didn't had the time to test it yet.
Can you give me some test ideas?
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150l support
From: Linus Walleij @ 2019-08-23 8:00 UTC (permalink / raw)
To: Vinod Koul
Cc: MSM, Bjorn Andersson, Andy Gross, Rob Herring, Mark Rutland,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org
In-Reply-To: <20190814123512.6017-3-vkoul@kernel.org>
On Wed, Aug 14, 2019 at 2:36 PM Vinod Koul <vkoul@kernel.org> wrote:
> Add support for the PM8150l GPIO support to the Qualcomm PMIC GPIO
> binding.
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150b support
From: Linus Walleij @ 2019-08-23 7:59 UTC (permalink / raw)
To: Vinod Koul
Cc: MSM, Bjorn Andersson, Andy Gross, Rob Herring, Mark Rutland,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org
In-Reply-To: <20190814123512.6017-2-vkoul@kernel.org>
On Wed, Aug 14, 2019 at 2:36 PM Vinod Koul <vkoul@kernel.org> wrote:
> Add support for the PM8150b GPIO support to the Qualcomm PMIC GPIO
> binding.
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150 support
From: Linus Walleij @ 2019-08-23 7:58 UTC (permalink / raw)
To: Vinod Koul
Cc: MSM, Bjorn Andersson, Andy Gross, Rob Herring, Mark Rutland,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org
In-Reply-To: <20190814123512.6017-1-vkoul@kernel.org>
On Wed, Aug 14, 2019 at 2:36 PM Vinod Koul <vkoul@kernel.org> wrote:
> Add support for the PM8150 GPIO support to the Qualcomm PMIC GPIO
> binding.
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Patch applied as lightweight and uncontroversial.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl/amd: disable spurious-firing GPIO IRQs
From: Linus Walleij @ 2019-08-23 7:56 UTC (permalink / raw)
To: Daniel Drake
Cc: open list:GPIO SUBSYSTEM, linux, Singh, Sandeep,
S-k, Shyam-sundar, Shah, Nehal-bakulchandra
In-Reply-To: <20190814090540.7152-1-drake@endlessm.com>
On Wed, Aug 14, 2019 at 11:05 AM Daniel Drake <drake@endlessm.com> wrote:
> 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>
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 5/5] pinctrl: mediatek: Add support for pin configuration dump via sysfs.
From: Linus Walleij @ 2019-08-23 7:52 UTC (permalink / raw)
To: Light Hsieh
Cc: moderated list:ARM/Mediatek SoC support, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Sean Wang
In-Reply-To: <1565686400-5711-6-git-send-email-light.hsieh@mediatek.com>
Hi Light,
thanks for your patch!
On Tue, Aug 13, 2019 at 10:53 AM Light Hsieh <light.hsieh@mediatek.com> wrote:
> From: Light Hsieh <light.hsieh@mediatek.com>
>
> Add support for pin configuration dump via catting
> /sys/kernel/debug/pinctrl/$platform_dependent_path/pinconf-pins.
This is debugfs so rename the subject "*debugfs"
> pinctrl framework had already support such dump. This patch implement the
> operation function pointer to fullfill this dump.
Fair enough, that's fine.
> Change-Id: Ib59212eb47febcd84140cbf84e1bd7286769beb0
This has been remarked on before.
This patch is missing your Signed-off-by, please fix that.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 0/5] Improve MediaTek pinctrl v2 and make backward compatible to smartphone mass production usage
From: Linus Walleij @ 2019-08-23 7:50 UTC (permalink / raw)
To: Light Hsieh
Cc: moderated list:ARM/Mediatek SoC support, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Sean Wang
In-Reply-To: <1565686400-5711-1-git-send-email-light.hsieh@mediatek.com>
On Tue, Aug 13, 2019 at 10:53 AM Light Hsieh <light.hsieh@mediatek.com> wrote:
> This patch improves MediaTek pinctrl v2 and makes backward compatible to
> current smartphone mass production usage by:
> 1.Check gpio pin number and use binary search in control address lookup
> 2.Supporting driving setting without mapping current to register value
> 3.Correct usage of PIN_CONFIG get/set implementation
I rely on Sean to review and get this in shape.
> 4.Backward compatible to previous Mediatek's bias-pull usage
This is fine as long as the new style of using explicit pull
setting also works. It's nice to be compatible.
> 5.Add support for pin configuration dump via sysfs
Do you mean debugfs? You should use debugfs for debug.
sysfs is subject to ABI rules.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: bcm2835: Pass irqchip when adding gpiochip
From: Linus Walleij @ 2019-08-23 7:46 UTC (permalink / raw)
To: open list:GPIO SUBSYSTEM, Eric Anholt, Stefan Wahren
Cc: Bartosz Golaszewski, Simon Arlott, Thierry Reding
In-Reply-To: <20190812062729.1892-1-linus.walleij@linaro.org>
On Mon, Aug 12, 2019 at 8:29 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> 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. The BCM2835 has multiple parents so let's
> exploit the new facility in the GPIO_IRQCHIP to actually
> deal with multiple parents.
>
> Cc: Simon Arlott <simon@arlott.org>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch is a bit scary because I haven't tried converting multiple
parents before. Any chance one of you RPi people could give it
a test run, so you don't have to experience testing it in linux-next?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/7] ARM: xscale: fix multi-cpu compilation
From: Linus Walleij @ 2019-08-23 7:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: soc, Russell King, Dan Williams, Vinod Koul, Bartosz Golaszewski,
Linux ARM, linux-kernel@vger.kernel.org, dmaengine,
open list:GPIO SUBSYSTEM, linux-i2c
In-Reply-To: <20190809163334.489360-5-arnd@arndb.de>
On Fri, Aug 9, 2019 at 6:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> Building a combined ARMv4+XScale kernel produces these
> and other build failures:
>
> /tmp/copypage-xscale-3aa821.s: Assembler messages:
> /tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode
> /tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode
> /tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode
OK we certainly need this.
> Add an explict .arch armv5 in the inline assembly to allow the ARMv5
> specific instructions regardless of the compiler -march= target.
You probably mean...
> +.arch xscale \n\
> pld [%0, #0] \n\
Explicit .arch xscale rather than .arch armv5.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 3/3] gpio: mpc8xxx: add ls1088a platform special function
From: Linus Walleij @ 2019-08-23 7:38 UTC (permalink / raw)
To: Hui Song
Cc: Shawn Guo, Li Yang, Rob Herring, Mark Rutland,
Bartosz Golaszewski, Linux ARM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <20190808101628.36782-3-hui.song_1@nxp.com>
On Thu, Aug 8, 2019 at 12:26 PM Hui Song <hui.song_1@nxp.com> wrote:
> From: Song Hui <hui.song_1@nxp.com>
>
> ls1028a and ls1088a platform share common special function.
> The gpio hardware what they use is the same version.
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 1/3] gpio: mpc8xxx: add ls1088a platform gpio node DT binding description
From: Linus Walleij @ 2019-08-23 7:37 UTC (permalink / raw)
To: Hui Song
Cc: Shawn Guo, Li Yang, Rob Herring, Mark Rutland,
Bartosz Golaszewski, Linux ARM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <20190808101628.36782-1-hui.song_1@nxp.com>
On Thu, Aug 8, 2019 at 12:26 PM Hui Song <hui.song_1@nxp.com> wrote:
> From: Song Hui <hui.song_1@nxp.com>
>
> ls1088a and ls1028a platform share common gpio node.
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
Patch applied with Rob's ACK!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 3/3] pinctrl: sh-pfc: Rollback to mux if requires when the gpio is freed
From: Geert Uytterhoeven @ 2019-08-23 7:10 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Linus Walleij, Geert Uytterhoeven, open list:GPIO SUBSYSTEM,
Linux-Renesas
In-Reply-To: <CAMuHMdW32TRw3Awf-5C2eJiZ1iys-vK7YihFwqPxOP66Eh9+Lg@mail.gmail.com>
On Thu, Aug 8, 2019 at 10:29 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Aug 8, 2019 at 8:20 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > R-Car PWM controller requires the gpio to output zero duty,
> > this patch allows to roll it back from gpio to mux when the gpio
> > is freed.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
FTR: as the PWM work is put on hold, I have changed the commit
description to:
pinctrl: sh-pfc: Rollback to mux if required when the gpio is freed
Some drivers require switching between function and gpio at run-time.
Allow to roll back from gpio to mux when the gpio is freed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox