CC irqchip Original thread at https://lore.kernel.org/lkml/20190607172958.20745-1-erosca@xxxxxxxxxxxxxx/ On Mon, Jun 10, 2019 at 10:30 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Kalle Valo <kvalo@xxxxxxxxxxxxxx> [190610 07:01]: > > Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> writes: > > > > > The wl1837mod datasheet [1] says about the WL_IRQ pin: > > > > > > ---8<--- > > > SDIO available, interrupt out. Active high. [..] > > > Set to rising edge (active high) on powerup. > > > ---8<--- > > > > > > That's the reason of seeing the interrupt configured as: > > > - IRQ_TYPE_EDGE_RISING on HiKey 960/970 > > > - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms > > > > > > We assert that all those platforms have the WL_IRQ pin connected > > > to the SoC _directly_ (confirmed on HiKey 970 [2]). > > > > > > That's not the case for R-Car Kingfisher extension target, which carries > > > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present > > > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively > > > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS > > > configuration we would need to use IRQ_TYPE_EDGE_FALLING or > > > IRQ_TYPE_LEVEL_LOW. > > > > > > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq: > > > support platform dependent interrupt types") made a special case out > > > of these interrupt types. After this commit, it is impossible to provide > > > an IRQ configuration via DTS which would describe an inverter present > > > between the WL18* chip and the SoC, generating the need for workarounds > > > like [3]. > > > > > > Create a boolean OF property, called "invert-irq" to specify that > > > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter. > > > > > > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using > > > the DTS configuration [4] combined with the "invert-irq" property. > > > > > > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf > > > [2] https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/ > > > [3] https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WLxxxx-side.patch > > > [4] https://patchwork.kernel.org/patch/10895879/ > > > ("arm64: dts: ulcb-kf: Add support for TI WL1837") > > > > > > Signed-off-by: Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> > > > > Tony&Eyal, do you agree with this? > > Yeah if there's some hardware between the WLAN device and the SoC > inverting the interrupt, I don't think we have clear a way to deal > with it short of setting up a separate irqchip that does the > translation. Yeah, inverting the interrupt type in DT works only for simple devices, that don't need configuration. A simple irqchip driver that just inverts the type sounds like a good solution to me. Does something like that already exists? > But in some cases we also do not want to invert the interrupt, so > I think this property should take IRQ_TYPE_EDGE_RISING and > IRQ_TYPE_EDGE_RISING values to override the setting for > the WLAN end of the hardware? > > Let's wait a bit longer for comments from Eyal too. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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
