Am Freitag, 6. Dezember 2019, 16:52:50 CET schrieb Miquel Raynal: > Hi Heiko, > > Heiko Stuebner <heiko@xxxxxxxxx> wrote on Fri, 06 Dec 2019 16:48:00 > +0100: > > > Hi Miquel, > > > > Am Freitag, 6. Dezember 2019, 16:42:47 CET schrieb Miquel Raynal: > > > PMIC interrupt can be active high or active low depending on BIT(1) of > > > the GPIO_INT_CFG pin. The default is 0x1, which means active > > > high. Change the polarity in the device tree to reflect the default > > > state. > > > > > > Without this and with the current code base, the interrupt never stops > > > triggering while the MFD driver does not see anything to > > > check/clear/mask so after 100000 spurious IRQs, the kernel simply > > > desactivates the interrupt: > > > > > > irq 36: nobody cared (try booting with the "irqpoll" option) > > > [...] > > > handlers: > > > [<(____ptrval____)>] irq_default_primary_handler threaded > > > [<(____ptrval____)>] regmap_irq_thread > > > Disabling IRQ #36 > > > > > > Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx> > > > > *coughs slightly* > > > > mfd: rk808: Set RK817 interrupt polarity to low > > https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/commit/drivers/mfd/rk808.c?h=for-mfd-next&id=dbd16ef53487084816a20f662423ab543a75fc83 > > > > Should be in the current merge window already I guess ;-) > > This time I swear I checked your tree. But this time we did not ended > with the same fix so I missed this one *again* :) No worries ... I guess I should check where I hid additional patches ;-) So right now px30 stuff is in the trees: - mine - mfd - phy (first round of dsi phy, refinement pending on the list) - nvmem (for the otp controller) - drm (drm/rockchip: vop: add the definition of dclk_pol) - clk and pending on lists: - drm (dsi support + timings) - phy (refinement as mentioned above) not submitted yet but planning to get this done this weekend: - panel driver for px30-evb - dsi devicetree stuff Hope this helps a bit to prevent more double work ;-) Heiko > > > > > Having this consistent over all rk8xx seemed nicer. > > I'm fine with this approach too. > > Thanks, > Miquèl