On Fri, Jan 29, 2021 at 10:31 AM Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > > Hi Bjorn/Rob, > > I've been trying to make a Hikey 970 board to work properly upstream. > > This specific hardware is similar to a previous model (Hikey 960), > and it uses the same PCIe driver, with a few additions > (drivers/pci/controller/dwc/pcie-kirin.c). > > The major difference between those two models is that, on Hikey 960, > the PCIe is mapped as [1]: > > +---------+ +--------+ > |Kirin 960|----> |PCIe M.2| > | SoC | | | > +---------+ +--------+ > > While, on Hikey 970, the connection is more complex[2]: > > +---------+ +--------+ > | | | | +--------+ > | | | |---->|PCIe M.2|-->M.2 slot > | | | | +--------+ > | | | | > | | | | +--------+ > |Kirin 970|----> |Switch |---->|Mini 1x |-->mini PCIe slot > | | |PEX 8606| +--------+ > | SoC | | | > | | | | +-------+ > | | | |---->|RTL8169|---> Ethernet > | | | | +-------+ > +---------+ +--------+ > > > > [1] see https://www.96boards.org/documentation/consumer/hikey/hikey960/hardware-docs/hardware-user-manual.md.html > [2] see https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/files/hikey970-schematics.pdf > > When the driver is properly loaded, this is what can be seen there: > > $ lspci > 00:00.0 PCI bridge: Huawei Technologies Co., Ltd. Device 3670 (rev 01) > 01:00.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) > 02:01.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) > 02:04.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) > 02:05.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) > 02:07.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) > 02:09.0 PCI bridge: PLX Technology, Inc. PEX 8606 6 Lane, 6 Port PCI Express Gen 2 (5.0 GT/s) Switch (rev ba) > 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) > > (without anything connected to M.2 or mini 1x slots) > > All devices after the SoC require a regulator line to be > enabled (LDO33). Starting the PCIe bus before turning them on > causes PCIe probe to fail. > > There are also separate PERST lines for the switch (Broadcom PEX 8606), > PCIe M.2, Mini 1x and for the Ethernet hardware (RTL 8169). > > To make it a little more fun, the M.2, the Mini 1x and the > RTL 8169 also requires a clockreq in order to work. Nice. Yet another case of a 'probeable' bus with non-probeable additions. Second one recently for PCI[1][2]. > Both the 4 PERST reset lines and the 3 CLOCKREQ lines are initialized > during the PCIe power on logic, at probing time. > > I'm currently thinking about the best way to report this via > device tree. > > It sounds to me that the best would be to add those 4 data at the DTS file: > > reset-gpios = <&gpio7 0 0 >, <&gpio25 2 0 >, > <&gpio3 1 0 >, <&gpio27 4 0 >; > reset-names = "pcie_switch_reset", "pcie_eth_reset", > "pcie_m_2_reset", "pcie_mini1_reset"; 'reset-names' is paired with 'resets', so this doesn't work. The name of the gpio is in the property name. > clkreq-gpios = <&gpio20 6 0 >, <&gpio27 3 0 >, > <&gpio17 0 0 >; > clkreq-names = "pcie_eth_clkreq", "pcie_m_2_clkreq", > "pcie_mini1_clkreq"; The larger problem here is this will work for exactly one board. Soon as you have a different topology, you'll have to change all this. If it's just assert/deassert all the GPIOs at once, then it could kind of work. If you need to know the mapping (which adding the names seems to imply), then it definitely doesn't work. You are going to need DT nodes representing the hierarchy you drew above with GPIO properties added to the appropriate child nodes. Controlling the regulator should be specific to the device. Controlling the GPIOs could be done by the PCI core given those are standard signals for PCI. Rob [1] https://lore.kernel.org/linux-devicetree/20210128175225.3102958-1-dmitry.baryshkov@xxxxxxxxxx/ [2] https://lore.kernel.org/linux-devicetree/CAA8EJpqPONJfQLFQhB3_AEdFYcZ8rKWJw7=wd7KzJRhOEr+w_A@xxxxxxxxxxxxxx/
