This series depends on this one:
https://lore.kernel.org/lkml/[email protected]/
It is available, with its patch dependencies against v5.14-rc1 at:
https://github.com/mchehab/linux/commits/pcie-alternate
This series add support at the pcie-kirin dirver for it to use a separate PHY driver.
Yet, in order to preserve the existing DT schema for Kirin 960, it keeps the
Kirin 960 PHY inside the pci driver. I tried to find a way to split it while keeping
the DT schema backward-compatible, but currently the PHY core doesn't allow
that, as it relies on a "phy" property at the pcie node in order to recognize the
PHY driver.
Once the pci-kiring is modified to support an external PHY driver, add a
Kirin 970 PHY and add the needed properties for the HiKey 970 board to
detect the PCIe.
It should be noticed that the HiKey 970 design uses 4 different GPIO pins, one
for each PERST# signal for each PCIe bus device:
- GPIO 56 has a pullup logic from 1V8 to 2V5
connected to a PCIe bridge chip (PEX 8606);
- GPIO 25 has a pullup logic from 1V8 to 3V3
connected to the PERST# pin at the M.2 slot;
- GPIO 220 has a pullup logic from 1V8 to 3V3
connected to the PERST# pin at the PCIe mini slot;
- GPIO 203 has a pullup logic from 1V8 to 3V3
connected to the PERST# pin at the Ethernet chipset.
At the first versions, those were mapped as part of the pci-bus, but the
pci-bus.yaml schema only allows a single PERST# GPIO. So, on v5, those
were moved to the PHY DT schema. However, as Rob complained, on this
version, I opted to add a separate patch (the last one) that moves those
back to the PCIe of-node.
If such patch 09/09 is accepted, then this patch for the DT schema should
also be accepted:
https://github.com/devicetree-org/dt-schema/pull/56
Tested on Hikey970:
$ 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)
$ ethtool enp6s0
Settings for enp6s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
netlink error: Operation not permitted
Link detected: yes
Also tested that Hikey 960 keeps being supported:
$ lspci
00:00.0 PCI bridge: Huawei Technologies Co., Ltd. Device 3660 (rev 01)
---
v7:
- Moved kirin_pcie_match to be closer to the probe function;
- Improved patch description for:
"PCI: kirin: add support for a PHY layer"
- Added missing MODULE_*() macros on both PCI and PHY drivers;
- Fixed a warning at hisilicon,phy-hi3670-pcie.yaml reported by
Rob Herring's bot.
v6:
- Use an alternative approach, in order to keep the Kirin 960 PHY internal to
the driver, in order to not break the DT schema. The PHY-specific code
were made self-contained at pcie-kirin, in order to make easier to split
it in the future, if needed.
v5:
- added "static" to hi3670_pcie_get_eyeparam() declaration on patch 6/8
v4:
- dropped the DTS patch, as it depends on a PMIC-related patch series;
- minor changes at the patch description;
- HiKey and HiSilicon are now using the preferred CamelCase format.
Manivannan Sadhasivam (1):
arm64: dts: HiSilicon: Add support for HiKey 970 PCIe controller
hardware
Mauro Carvalho Chehab (9):
PCI: kirin: Reorganize the PHY logic inside the driver
PCI: kirin: Add support for a PHY layer
PCI: kirin: Use regmap for APB registers
PCI: kirin: Add MODULE_* macros
dt-bindings: PCI: kirin: Fix compatible string
dt-bindings: phy: Add bindings for HiKey 970 PCIe PHY
phy: HiSilicon: Add driver for Kirin 970 PCIe PHY
dt-bindings: PCI: kirin-pcie.txt: Convert it to yaml
phy-hi3670-pcie: Move reset-gpios to the PCIe DT schema
.../bindings/pci/hisilicon,kirin-pcie.yaml | 87 ++
.../devicetree/bindings/pci/kirin-pcie.txt | 50 -
.../devicetree/bindings/pci/snps,dw-pcie.yaml | 2 +-
.../phy/hisilicon,phy-hi3670-pcie.yaml | 88 ++
MAINTAINERS | 2 +-
arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 70 ++
.../boot/dts/hisilicon/hikey970-pmic.dtsi | 1 -
drivers/pci/controller/dwc/pcie-kirin.c | 413 +++++---
drivers/phy/hisilicon/Kconfig | 10 +
drivers/phy/hisilicon/Makefile | 1 +
drivers/phy/hisilicon/phy-hi3670-pcie.c | 902 ++++++++++++++++++
11 files changed, 1429 insertions(+), 197 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml
delete mode 100644 Documentation/devicetree/bindings/pci/kirin-pcie.txt
create mode 100644 Documentation/devicetree/bindings/phy/hisilicon,phy-hi3670-pcie.yaml
create mode 100644 drivers/phy/hisilicon/phy-hi3670-pcie.c
--
2.31.1
There's nothing preventing this driver to be loaded as a
module. So, change its config from bool to tristate.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
---
drivers/pci/controller/dwc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index 423d35872ce4..e0091bfae5b5 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -227,7 +227,7 @@ config PCIE_INTEL_GW
config PCIE_KIRIN
depends on OF && (ARM64 || COMPILE_TEST)
- bool "HiSilicon Kirin series SoCs PCIe controllers"
+ tristate "HiSilicon Kirin series SoCs PCIe controllers"
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
help
--
2.31.1
On Wed, Jul 21, 2021 at 12:15 PM Mauro Carvalho Chehab
<[email protected]> wrote:
>
> There's nothing preventing this driver to be loaded as a
> module. So, change its config from bool to tristate.
>
> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
No objections from me, but I wonder if you would also consider making the
module removable. It's currently marked as 'builtin_platform_driver',
so you can load but not remove it. Rob has done some bug fixes that make
it possible to remove similar drivers, so it's probably not much work
here either.
Arnd
Em Wed, 21 Jul 2021 13:55:07 +0200
Arnd Bergmann <[email protected]> escreveu:
> On Wed, Jul 21, 2021 at 12:15 PM Mauro Carvalho Chehab
> <[email protected]> wrote:
> >
> > There's nothing preventing this driver to be loaded as a
> > module. So, change its config from bool to tristate.
> >
> > Signed-off-by: Mauro Carvalho Chehab <[email protected]>
>
> No objections from me, but I wonder if you would also consider making the
> module removable. It's currently marked as 'builtin_platform_driver',
> so you can load but not remove it. Rob has done some bug fixes that make
> it possible to remove similar drivers, so it's probably not much work
> here either.
Yeah, I can probably work on a patch to unbind/remove this driver.
Never actually tried to write a patch removing the PCIe BUS, so no
idea if the refcounts for the in-board Ethernet NIC, M.2 and mini-PCIe
slots will be properly handled. If refcount is handled properly, I
guess a patch like that won't be hard, at least for Kirin 970 PHY.
The Kirin 960 PHY will require a small change at the current version,
as it currently misses the power_off logic.
I also need to double-check if devm resources will be freed at the
driver removal time, as, with some past tests with media devices,
we had some issues with that.
Thanks,
Mauro