Re: bcm2711 / RPi4 not functional after d62069c22eda

[Miguel Angel Ajo <majopela@xxxxxxxxxx>]

Thank you for the feedback, and sorry for not posting to linux-spi in
the first message.

On Fri, Mar 18, 2022 at 4:31 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote:
>
>
>
> On 3/18/2022 5:59 AM, Lukas Wunner wrote:
> > [cc += linux-spi; please do not write developers directly without cc'ing
> > relevant lists]
> >
> > On Fri, Mar 18, 2022 at 11:54:35AM +0100, Miguel Angel Ajo wrote:
> >> On Fri, Mar 18, 2022 at 11:47 AM Miguel Angel Ajo <majopela@xxxxxxxxxx>
> >> wrote:
> >>>      I wanted to share a regression found after commit:
> >>>
> >>> d62069c22eda spi: bcm2835: Remove shared interrupt support
> > [...]
> >>> After this commit I get:
> >>>
> >>> [root@rpi4-64 ~]# dmesg | grep spi
> >>> [   18.781250] spi-bcm2835 fe204000.spi: could not register SPI
> >>> controller: -517
> >>> [   19.134138] spi-bcm2835 fe204000.spi: could not register SPI
> >>> controller: -517
> >>> [   19.895147] spi-bcm2835 fe204000.spi: could not register SPI
> >>> controller: -517
> >>> [   20.400137] spi-bcm2835 fe204000.spi: could not register SPI
> >>> controller: -517
> >
> > Those are transient errors, -517 is -EPROBE_DEFER.  Probing fails
> > because a resource is not available (yet), to be retried again later
> > if/when it becomes available.

Whatever it's looking for doesn't become available.

I have noticed that upstream kernel with the device tree provided by
raspberry/linux
master downstream it works ,and I'm trying to identify what's missing or wrong.

At least to my understanding we should be able to start at least one
SPI controller
without shared interrupt support. But it's not the case for me.

>
> You would want to check whether you have these two commits in your tree
> as well:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=266423e60ea1b953fcc0cd97f3dad85857e434d1
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8f24c58d1b69ecf410a673c22f546dc732bb879
>
> or neither, because the first commit forces a lockstep update of the DTS.

Thanks, I checked and both, the rpi/linux master, and the kernel I'm
working with ( 5.16.9-200.fc35.aarch64)

>
> The SPI driver does not uses that many shared resources besides
> interrupts, clocks and chip-select overs GPIOs, the first one is
> unlikely to be the problem, and so is the second, thus leaving the third
> resource as a candidate to defer on.

Thank you, I will continue with the investigation.

>
> >
> >
> >>> ecfbd3c introduced support for the bcm2711 SoC that shares
> >>> one interrupt over multiple spi controller instances.
> >>>
> >>> Do we have a more detailed description of the exact issue for
> >>> which we reverted?, is there a plan to re-introduce the shared interrupt
> >>> support while fixing the issue?
> >
> > See here for why the commit was reverted:
> >
> > https://lore.kernel.org/linux-spi/20200529174358.som3snunfxch6phi@xxxxxxxxx/
> >
> > There was a second attempt to introduce shared interrupt support,
> > but after a lengthy discussion, it was not pursued to fruition:
> >
> > https://lore.kernel.org/linux-spi/20200604212819.715-1-f.fainelli@xxxxxxxxx/
> >
> > So I believe shared interrupt support only exists in the Raspberry Pi
> > Foundation's downstream kernel, but not yet in the mainline kernel.
> >
> > Thanks,
> >
> > Lukas
>
> --
> Florian
>


-- 
Miguel Ángel Ajo  @mangel_ajo
Office of CTO EDGE team.
ex Submariner (ACM) and OpenStack networking