* Re: bcm2711 / RPi4 not functional after d62069c22eda [not found] ` <CAC3B9fkpO13QhCgVO-qyynbwdh_z60CKgpUhn-40NyGNGz_q8Q@mail.gmail.com> @ 2022-03-18 12:59 ` Lukas Wunner 2022-03-18 15:31 ` Florian Fainelli 0 siblings, 1 reply; 3+ messages in thread From: Lukas Wunner @ 2022-03-18 12:59 UTC (permalink / raw) To: Miguel Angel Ajo Cc: Mark Brown, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Nicolas Saenz Julienne, Javier Martinez Canillas, linux-spi [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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bcm2711 / RPi4 not functional after d62069c22eda 2022-03-18 12:59 ` bcm2711 / RPi4 not functional after d62069c22eda Lukas Wunner @ 2022-03-18 15:31 ` Florian Fainelli 2022-03-18 16:17 ` Miguel Angel Ajo 0 siblings, 1 reply; 3+ messages in thread From: Florian Fainelli @ 2022-03-18 15:31 UTC (permalink / raw) To: Lukas Wunner, Miguel Angel Ajo Cc: Mark Brown, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Nicolas Saenz Julienne, Javier Martinez Canillas, linux-spi 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bcm2711 / RPi4 not functional after d62069c22eda 2022-03-18 15:31 ` Florian Fainelli @ 2022-03-18 16:17 ` Miguel Angel Ajo 0 siblings, 0 replies; 3+ messages in thread From: Miguel Angel Ajo @ 2022-03-18 16:17 UTC (permalink / raw) To: Florian Fainelli Cc: Lukas Wunner, Mark Brown, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Nicolas Saenz Julienne, Javier Martinez Canillas, linux-spi 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-03-18 16:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAC3B9fn9DWezr3rspLbomuRLtRjSvW89cLMWR9TTCYsX=PDM_w@mail.gmail.com>
[not found] ` <CAC3B9fkpO13QhCgVO-qyynbwdh_z60CKgpUhn-40NyGNGz_q8Q@mail.gmail.com>
2022-03-18 12:59 ` bcm2711 / RPi4 not functional after d62069c22eda Lukas Wunner
2022-03-18 15:31 ` Florian Fainelli
2022-03-18 16:17 ` Miguel Angel Ajo
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.