raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.17k stars 5.01k forks source link

5.10.14 Pi4 vc4-kms-v3d results in i2c-0 and i2c-1 not probing #4132

Closed 6by9 closed 3 years ago

6by9 commented 3 years ago

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, then dtparam=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.

6by9 commented 3 years ago

93a3b097c467 ARM: dts: bcm2711: Add the BSC interrupt controller looks to be the commit that causes the trouble.

pelwell commented 3 years ago

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.

pelwell commented 3 years ago

Phew,

6by9 commented 3 years ago

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!)

6by9 commented 3 years ago
&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.

6by9 commented 3 years ago

@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.

6by9 commented 3 years ago

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.

6by9 commented 3 years ago

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.

6by9 commented 3 years ago

Revert merged, so closing.

popcornmix commented 3 years ago

This should be in latest rpi-update kernel.