| Message ID | cover.1748526284.git.andrea.porta@suse.com |
|---|---|
| Headers | show |
| Series | Add support for RaspberryPi RP1 PCI device using a DT overlay | expand |
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:38 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > Add device tree bindings for the clock generator found in RP1 multi > function device, and relative entries in MAINTAINERS file. > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > --- Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks! -- Florian
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:39 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > Add device tree bindings for the gpio/pin/mux controller that is part of > the RP1 multi function device, and relative entries in MAINTAINERS file. > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > --- Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks! -- Florian
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:45 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > The RP1 found on Raspberry Pi 5 board needs an external crystal at 50MHz. > Add clk_rp1_xosc node to provide that. > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > --- Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks! -- Florian
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:47 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > Define the RP1 node in an overlay. The inclusion tree is > as follow (the arrow points to the includer): > > rp1.dtso > ^ > | > rp1-common.dtsi ----> rp1-nexus.dtsi > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > --- Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks! -- Florian
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:42 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > The RP1 is an MFD supporting a gpio controller and /pinmux/pinctrl. > Add minimum support for the gpio only portion. The driver is in > pinctrl folder since upcoming patches will add the pinmux/pinctrl > support where the gpio part can be seen as an addition. > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > Reviewed-by: Stefan Wahren <wahrenst@gmx.net> > --- Applied to https://github.com/Broadcom/stblinux/commits/drivers/next, thanks! -- Florian
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:44 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > The RaspberryPi RP1 is a PCI multi function device containing > peripherals ranging from Ethernet to USB controller, I2C, SPI > and others. > > Implement a bare minimum driver to operate the RP1, leveraging > actual OF based driver implementations for the on-board peripherals > by loading a devicetree overlay during driver probe if the RP1 > node is not already present in the DT. > > The peripherals are accessed by mapping MMIO registers starting > from PCI BAR1 region. > > With the overlay approach we can achieve more generic and agnostic > approach to managing this chipset, being that it is a PCI endpoint > and could possibly be reused in other hw implementations. The > presented approach is also used by Bootlin's Microchip LAN966x > patchset (see link) as well, for a similar chipset. > In this case, the inclusion tree for the DT overlay is as follow > (the arrow points to the includer): > > rp1-pci.dtso <---- rp1-common.dtsi > > On the other hand, to ensure compatibility with downstream, this > driver can also work with a DT already comprising the RP1 node, so > the dynamically loaded overlay will not be used if the DT is already > fully defined. > > The reason why this driver is contained in drivers/misc has > been paved by Bootlin's LAN966X driver, which first used the > overlay approach to implement non discoverable peripherals behind a > PCI bus. For RP1, the same arguments apply: it's not used as an SoC > since the driver code is not running on-chip and is not like an MFD > since it does not really need all the MFD infrastructure (shared regs, > etc.). So, for this particular use, misc has been proposed and deemed > as a good choice. For further details about that please check the links. > > This driver is heavily based on downstream code from RaspberryPi > Foundation, and the original author is Phil Elwell. > > Link: https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf > Link: https://lore.kernel.org/all/20240612140208.GC1504919@google.com/ > Link: https://lore.kernel.org/all/83f7fa09-d0e6-4f36-a27d-cee08979be2a@app.fastmail.com/ > Link: https://lore.kernel.org/all/2024081356-mutable-everyday-6f9d@gregkh/ > Link: https://lore.kernel.org/all/20240808154658.247873-1-herve.codina@bootlin.com/ > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Acked-by: Bjorn Helgaas <bhelgaas@google.com> # quirks.c, pci_ids.h > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > --- Applied to https://github.com/Broadcom/stblinux/commits/drivers/next, thanks! -- Florian
From: Florian Fainelli <f.fainelli@gmail.com> On Thu, 29 May 2025 15:50:49 +0200, Andrea della Porta <andrea.porta@suse.com> wrote: > The RP1 driver uses the infrastructure enabled by OF_OVERLAY config > option. Enable that option in defconfig in order to produce a kernel > usable on RaspberryPi5 avoiding to enable it separately. > > Signed-off-by: Andrea della Porta <andrea.porta@suse.com> > Reviewed-by: Stefan Wahren <wahrenst@gmx.net> > Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> > --- Applied to https://github.com/Broadcom/stblinux/commits/defconfig-arm64/next, thanks! -- Florian
On 5/29/25 23:03, Arnd Bergmann wrote: > On Thu, May 29, 2025, at 16:00, Andrea della Porta wrote: >> Hi Krzysztof, >> >> On 15:50 Thu 29 May , Krzysztof Kozlowski wrote: >>> On 29/05/2025 15:50, Andrea della Porta wrote: >>>> *** RESENDING PATCHSET AS V12 SINCE LAST ONE HAS CLOBBERED EMAIL Message-Id *** >>>> >>> Can you slow down please? It's merge window and you keep sending the >>> same big patchset third time today. >> >> Sorry for that, I was sending it so Florian can pick it up for this >> merge window, and I had some trouble with formatting. Hopefully >> this was the last one. > > That's not how the merge window works, you missed 6.16 long ago: > > Florian sent his pull requests for 6.16 in early may, see > https://lore.kernel.org/linux-arm-kernel/20250505165810.1948927-1-florian.fainelli@broadcom.com/ > > and he needed time to test the contents before sending them to me. > > If the driver is ready to be merged now, Florian can pick it up > after -rc1 is out, and then include it in the 6.17 pull requests > so I can include them in the next merge window. I have applied all of the patches in the respective branch as we had discussed with Andrea and also merged all of the branches into my "next" branch so we can give this some proper soak testing. Once 6.16-rc1 is available, all those branches (devicetree/next, defconfig-arm64/next, drivers/next, etc.) will be rebased against that tag such that the patches that are already included will be dropped, and only this patch set plus what I have accumulated will be applied on top (if that makes sense). As Arnd says though, this is too late for 6.16 so this would be included in 6.17. Andrea, thank you very much for your persistence working on this patch series, and sorry that the request to merge those patches came in during a time where I was away. The good news is that I am not doing that again anytime soon. Thank you!
Hi Florian, On 16:46 Fri 30 May , Florian Fainelli wrote: > On 5/29/25 23:03, Arnd Bergmann wrote: > > On Thu, May 29, 2025, at 16:00, Andrea della Porta wrote: > > > Hi Krzysztof, > > > > > > On 15:50 Thu 29 May , Krzysztof Kozlowski wrote: > > > > On 29/05/2025 15:50, Andrea della Porta wrote: > > > > > *** RESENDING PATCHSET AS V12 SINCE LAST ONE HAS CLOBBERED EMAIL Message-Id *** > > > > > > > > > Can you slow down please? It's merge window and you keep sending the > > > > same big patchset third time today. > > > > > > Sorry for that, I was sending it so Florian can pick it up for this > > > merge window, and I had some trouble with formatting. Hopefully > > > this was the last one. > > > > That's not how the merge window works, you missed 6.16 long ago: > > > > Florian sent his pull requests for 6.16 in early may, see > > https://lore.kernel.org/linux-arm-kernel/20250505165810.1948927-1-florian.fainelli@broadcom.com/ > > > > and he needed time to test the contents before sending them to me. > > > > If the driver is ready to be merged now, Florian can pick it up > > after -rc1 is out, and then include it in the 6.17 pull requests > > so I can include them in the next merge window. > > I have applied all of the patches in the respective branch as we had > discussed with Andrea and also merged all of the branches into my "next" > branch so we can give this some proper soak testing. Once 6.16-rc1 is > available, all those branches (devicetree/next, defconfig-arm64/next, > drivers/next, etc.) will be rebased against that tag such that the patches > that are already included will be dropped, and only this patch set plus what > I have accumulated will be applied on top (if that makes sense). > > As Arnd says though, this is too late for 6.16 so this would be included in > 6.17. Andrea, thank you very much for your persistence working on this patch > series, and sorry that the request to merge those patches came in during a > time where I was away. The good news is that I am not doing that again > anytime soon. It was a pleasure, and many thanks for your patience too. Andrea > > Thank you! > -- > Florian
On 6/2/25 00:56, Andrea della Porta wrote: > Hi Florian, > > On 16:46 Fri 30 May , Florian Fainelli wrote: >> On 5/29/25 23:03, Arnd Bergmann wrote: >>> On Thu, May 29, 2025, at 16:00, Andrea della Porta wrote: >>>> Hi Krzysztof, >>>> >>>> On 15:50 Thu 29 May , Krzysztof Kozlowski wrote: >>>>> On 29/05/2025 15:50, Andrea della Porta wrote: >>>>>> *** RESENDING PATCHSET AS V12 SINCE LAST ONE HAS CLOBBERED EMAIL Message-Id *** >>>>>> >>>>> Can you slow down please? It's merge window and you keep sending the >>>>> same big patchset third time today. >>>> >>>> Sorry for that, I was sending it so Florian can pick it up for this >>>> merge window, and I had some trouble with formatting. Hopefully >>>> this was the last one. >>> >>> That's not how the merge window works, you missed 6.16 long ago: >>> >>> Florian sent his pull requests for 6.16 in early may, see >>> https://lore.kernel.org/linux-arm-kernel/20250505165810.1948927-1-florian.fainelli@broadcom.com/ >>> >>> and he needed time to test the contents before sending them to me. >>> >>> If the driver is ready to be merged now, Florian can pick it up >>> after -rc1 is out, and then include it in the 6.17 pull requests >>> so I can include them in the next merge window. >> >> I have applied all of the patches in the respective branch as we had >> discussed with Andrea and also merged all of the branches into my "next" >> branch so we can give this some proper soak testing. Once 6.16-rc1 is >> available, all those branches (devicetree/next, defconfig-arm64/next, >> drivers/next, etc.) will be rebased against that tag such that the patches >> that are already included will be dropped, and only this patch set plus what >> I have accumulated will be applied on top (if that makes sense). >> >> As Arnd says though, this is too late for 6.16 so this would be included in >> 6.17. Andrea, thank you very much for your persistence working on this patch >> series, and sorry that the request to merge those patches came in during a >> time where I was away. The good news is that I am not doing that again >> anytime soon. > > It was a pleasure, and many thanks for your patience too. As a heads up, the kernel robot reported a build failure for devicetree/next due to the missing pcie1 label, I have moved the DT patches from devicetree/next to devicetree-arm64/next where Stanimir's patches adding 2712 PCIe are already present. Thanks!
*** RESENDING PATCHSET AS V12 SINCE LAST ONE HAS CLOBBERED EMAIL Message-Id *** RP1 is an MFD chipset that acts as a south-bridge PCIe endpoint sporting a pletora of subdevices (i.e. Ethernet, USB host controller, I2C, PWM, etc.) whose registers are all reachable starting from an offset from the BAR address. The main point here is that while the RP1 as an endpoint itself is discoverable via usual PCI enumeraiton, the devices it contains are not discoverable and must be declared e.g. via the devicetree. This patchset is an attempt to provide a minimum infrastructure to allow the RP1 chipset to be discovered and perpherals it contains to be added from a devictree overlay loaded during RP1 PCI endpoint enumeration. To ensure compatibility with downstream, a devicetree already comprising the RP1 node is also provided, so it's not strictly necessary to use the dynamically loaded overlay if the devicetree is already fully defined at the origin. To achieve this modularity, the RP1 node DT definitions are arranged by file inclusion as per following schema (the arrow points to the includer, see also [9]): rp1-pci.dtso rp1.dtso ^ ^ | | rp1-common.dtsi ----> rp1-nexus.dtsi ----> bcm2712-rpi-5-b.dts ^ | bcm2712-rpi-5-b-ovl-rp1.dts Followup patches should add support for the several peripherals contained in RP1. This work is based upon dowstream drivers code and the proposal from RH et al. (see [1] and [2]). A similar approach is also pursued in [3]. The patches are ordered as follows: -PATCHES 1 to 3: add binding schemas for clock, gpio and RP1 peripherals. They are needed to support the other peripherals, e.g. the ethernet mac depends on a clock generated by RP1 and the phy is reset through the on-board gpio controller. -PATCH 4 and 5: add clock and gpio device drivers. -PATCH 6: the devicetree node describing the RP1 chipset. -PATCH 7: this is the main patch to support RP1 chipset. It can work either with a fully defined devicetree (i.e. one that already included the rp1 node since boot time) or with a runtime loaded dtb overlay which is linked as binary blob in the driver obj. This duality is useful to comply with both downstream and upstream needs (see [9]). The real dtso is in devicetree folder while the dtso in driver folder is just a placeholder to include the real dtso. In this way it is possible to check the dtso against dt-bindings. The reason why drivers/misc has been selected as containing folder for this driver can be seen in [6], [7] and [8]. -PATCH 8: add the external clock node (used by RP1) to the main dts. -PATCH 9: the fully fledged devictree containing also the rp1 node. This devicetree is functionally similar to the one downstream is using. -PATCH 10 (OPTIONAL): this patch introduces a new scenario about how the rp1 node is specified and loaded in DT. On top of the base DT (without rp1 node), the fw loads this overlay and the end result is the same devicetree as in patch 9, which is then passed to the next stage (either the kernel or u-boot/bootloader). While this patch is not strictly necessary and can therefore be dropped (see [10]), it's not introducing much extra work and maybe can come in handy while debugging. -PATCH 11: add the relevant kernel CONFIG_ options to defconfig. -PATCH 12: enable CONFIG_OF_OVERLAY in order for 'make defconfig' to produce a configuration valid for the RP1 driver. Without this patch, the user has to explicitly enable it since the misc driver depends on OF_OVERLAY. -PATCH 13: collect all changes for MAINTAINERS file. This patchset is also a first attempt to be more agnostic wrt hardware description standards such as OF devicetree and ACPI, where 'agnostic' means "using DT in coexistence with ACPI", as been already promoted by e.g. AL (see [4]). Although there's currently no evidence it will also run out of the box on purely ACPI system, it is a first step towards that direction. Many thanks, Andrea della Porta Links: - [1]: https://lpc.events/event/17/contributions/1421/attachments/1337/2680/LPC2023%20Non-discoverable%20devices%20in%20PCI.pdf - [2]: https://lore.kernel.org/lkml/20230419231155.GA899497-robh@kernel.org/t/ - [3]: https://lore.kernel.org/all/20240808154658.247873-1-herve.codina@bootlin.com/#t - [4]: https://lore.kernel.org/all/73e05c77-6d53-4aae-95ac-415456ff0ae4@lunn.ch/ - [5]: https://lore.kernel.org/all/20240626104544.14233-1-svarbanov@suse.de/ - [6]: https://lore.kernel.org/all/20240612140208.GC1504919@google.com/ - [7]: https://lore.kernel.org/all/83f7fa09-d0e6-4f36-a27d-cee08979be2a@app.fastmail.com/ - [8]: https://lore.kernel.org/all/2024081356-mutable-everyday-6f9d@gregkh/ - [9]: https://lore.kernel.org/all/Z87wTfChRC5Ruwc0@apocalypse/ - [10]: https://lore.kernel.org/all/CAMEGJJ0f4YUgdWBhxvQ_dquZHztve9KO7pvQjoDWJ3=zd3cgcg@mail.gmail.com/#t CHANGES IN V12 VERSUS V9 PATCH RELATED ------------------------------------------------- - Patch 10,11,12: Added: Reviewed-by: Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> - Patches reworked to apply cleanly on broadcom/stblinux branches: patch 1,2,3,6,8,9,10 -> devicetree/next patch 11,12 -> defconfig/next patch 4,5,7 -> drivers/next patch 13 -> maintainers/next - Patch 13: new patch gathering all changes for MAINTAINERS - Patch 7: Added: Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> RP1 CLOCK DRIVER ------------------------------------ - Dropped some WARN_ONCE() lines that are basically useless - rp1_clock_set_parent() now returns EINVAL in case the parent check is failing. As a result, rp1_clock_set_rate_and_parent() has also been adapted to return rp1_clock_set_parent() retcode. - Return an ERR_PTR from rp1_register_clock() instead of just NULL - Dropped some unaesthetic blank lines - Disabled the builtin locking in regmap since we're already dealing with concurrency in the code - rp1_clk_probe(): dropped dev_err_probe() as redundant due to commit 12a0fd23e870 ("clk: Print an error when clk registration fails")