Re: bcm2711 / RPi4 not functional after d62069c22eda

Re: bcm2711 / RPi4 not functional after d62069c22eda

[Lukas Wunner]

[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@redhat.com>
> 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.


> > 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@wunner.de/

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@gmail.com/

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

Re: bcm2711 / RPi4 not functional after d62069c22eda

[Florian Fainelli]

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

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.

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.

> 
> 
>>> 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@wunner.de/
> 
> 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@gmail.com/
> 
> 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

Re: bcm2711 / RPi4 not functional after d62069c22eda

[Miguel Angel Ajo]

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@gmail.com> 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@redhat.com>
> >> 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@wunner.de/
> >
> > 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@gmail.com/
> >
> > 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