Closed 6by9 closed 3 years ago
93a3b097c467 ARM: dts: bcm2711: Add the BSC interrupt controller looks to be the commit that causes the trouble.
While I'm no stranger to failure, I was testing I2C heavily during the development of https://github.com/raspberrypi/linux/commit/431ac1d21b5e842c5a564bc0bab31d7dc11611f5, so it's hard to see how something as simple as a failure to initialise could happen.
Phew,
It does require vc4-kms-v3d to be loaded, otherwise all is good anyway.
(As you know I'm trying to get the DSI panels working, therefore want the I2C to the touchpanel an regulator. Updated and it all went to pot!)
&i2c0if {
compatible = "brcm,bcm2711-i2c", "brcm,bcm2835-i2c";
interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
};
bsc_intr: interrupt-controller@7ef00040 {
compatible = "brcm,bcm2711-l2-intc", "brcm,l2-intc";
reg = <0x7ef00040 0x30>;
interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <1>;
};
Need to check the docs that the bsc_intr interrupt is correct (it works so probably is), but they'll have to play nicely and share the interrupt.
@mripard Sorry quick ping as you may know off the top of your head. It looks like the bsc_intr block shares the interrupt with all the other I2C peripherals.
Any quick way to make the interrupt controller share the interrupt? Normally it'd be requested with request_irq(..., IRQF_SHARED, ...)
, but the request_irq call seems to be slightly buried in framework.
Thanks.
OK, so i2c-brcmstb can work without the interrupt (that was how it was working before https://github.com/raspberrypi/linux/commit/93a3b097c467bd5efc1ae3a271c336fdad3b2108
So the quickest "fix" for now is to revert that one patch and drop back to non-interrupt behaviour whilst the controller issue is investigated. Testing that now, and I'll report upstream too.
So there isn't an easy way to make an interrupt controller share the parent interrupt. https://lists.freedesktop.org/archives/dri-devel/2021-February/297197.html
Indeed, it looks like setting an equivalent to IRQF_SHARED would be the solution, but I couldn't find anything that would allow us to in the irqchip code.
Marc, Thomas, is it something that is allowed?
No, not really. That's because the chained handler is actually an interrupt flow, and not a normal handler. IRQF_SHARED acts at the wrong level for that.
I can see two possibilities:
the l2-intc gets turned into a normal handler, and does the demux from there. Horrible stuff.
the i2c controller gets parented to the l2c-int as a fake interrupt, and gets called from there. Horrible stuff.
Pick your poison... :-/
Option 3 is to drop the interrupt controller again. I'll sort a PR for that.
Revert merged, so closing.
This should be in latest rpi-update kernel.
Placeholder for notes rather than posting on the bottom of #3999 (the suspected cause of the issue)
If
dtoverlay=vc4-kms-v3d
is present in config.txt, thendtparam=i2c_arm=on
fails to load i2c_bcm2835 with[ 6.647857] i2c-bcm2835 fe804000.i2c: Could not request IRQ
5.10.13 at https://github.com/raspberrypi/linux/commit/98a26692449ad74be15a25c05bb5be5396aaea4f works fine.
That leaves the CEC support, or possibly Phil's I2C bug fix in 431ac1d21b5e842c5a564bc0bab31d7dc11611f5 as the likely candidates.
I'm working through it, but I'm building on my laptop so it's not the fastest.