Re: [PATCH v5 0/2] PCI: mediatek-gen3: Add 2-lanes mode support + clock
Benjamin Larsson <[email protected]>
| Newsgroups | org.infradead.lists.linux-mediatek,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
On 09/08/2026 16:14, Christian Marangi (Ansuel) wrote: > Il giorno dom 9 ago 2026 alle ore 16:08 Benjamin Larsson > <[email protected]> ha scritto: >> >> On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote: >>> Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas >>> <[email protected]> ha scritto: >>>> >>>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote: >>>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <[email protected]> wrote: >>>>>> This small series introduce support for 2-lanes mode for Airoha AN7581 >>>>> >>>>> Just a nitpick, but I would probably name this something else, like >>>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already >>>>> has 2x lanes as a standard feature, so this naming is a bit confusing. >>>>> It's not like dual-LVDS display in which LVDS is only a single lane. >>>> >>>> I suggested the "2-lane" and "x2" terminology because I assumed the >>>> result is what the PCIe spec would describe as a "x2 Link" consisting >>>> of two Lanes. >>>> >>>> If that's not the case, maybe "cross-controller lane-bonding mode" or >>>> "lane stealing" would be more accurate, but I don't know what those >>>> mean, so if we use them I would also like to know what the result >>>> looks like in standard PCIe terms. >>>> >>> >>> Mhhh I don't really like the term lane stealing. Also cross-controller >>> lane-bonding >>> might be a first. Even if correct it would complicate identification >>> of the feature >>> that at the end of the day configures the HW to provide a 2 lanes PCIe. >>> >>> Consider that in such mode, the other PCIe controller gets disabled (this is >>> handled in DT) so it's effectively enabling the standard PCIe 2x lanes >>> and apply the HW configuration for it. >>> >>>>>> SoC. This is needed for correctly functionality of Eagle WiFi Card >>>>>> normally attached to this SoC that require a 2-line PCIe card to >>>>>> correctly work (and give the proper performance) >>>>>> >>>>>> The first 2 patch address a limitation of the PCIe implementation >>>>>> where the PERSTOUT reset were indirectly asserted and deasserted >>>>>> all at the same time (for all the 3 PCIe card) with PCIe >>>>>> enable and disable. >>>>>> The 2 patch address this and introduce correct reset to control >>>>>> reset line for the relevant PCIe line. >>>>>> >>>>>> The last 2 patch add additional logic and support to assert >>>>>> and deassert the PERSTOUT and also apply the required configuration >>>>>> for 2-lanes mode. >>>>>> >>>>>> 2-lanes mode is implemented in DT by adding the required property >>>>>> and by defining the "num-lanes" to 2. >>> >> >> Hi. Isnt this just pcie bifurcation? >> >> Logically bifurcation would need to be disabled when using 2 lanes in >> one slot and enabled when 2 lanes are split between 2 pcie slots. >> >> But I'm not really sure what value a bifurcation property would add. >> Isnt the current schema enough? >> >> The mt7987 will need the same logic as it can also bifurcate one pcie slot. >> > > The documentation is not so kind on these kind of details... and no register > for bifurcation... maybe it's the mux one? But the mux settings comes from > reverse as in documentation that SCU register is a good 7:0 bits of > data value... Hi, yeah I think the SCU documentation is wrong for the AN7581. At least for the W1700k v1 device SoC version. It works without the SCU PCIC bit set there IIRC. https://forum.openwrt.org/t/quantum-fiber-w1700k-support/222776/280 The vendor driver has this: https://github.com/merbanan/airoha_pcie/blob/main/airoha_pcie/en7581/pcie-ecnt-phy_7581.c#L1671 Maybe this is the only bit that control the bifurcation? MvH Benjamin Larsson