…en4 2-lanes PHY

The fourth and sixth PCIe instances on Glymur are both Gen4 2-lane PHY.
So document the compatible.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>

Glymur platform has two Gen4 2-lanes controllers, the fourth and
sixth instances. Add support for their PHYs.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Abel Vesa <[email protected]>

On the Qualcomm Glymur platform the PCIe host is compatible with the DWC
controller present on the X1E80100 platform. So document the PCIe
controllers found on Glymur and use the X1E80100 compatible string as a
fallback in the schema.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Prudhvi Yarlagadda <[email protected]>
Signed-off-by: Wenbin Yao <[email protected]>
Acked-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>

… compatible

Document compatible for the QMP PCIe PHY on Kaanapali platform.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Jingyi Wang <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>

…egister offsets

Kaanapali SoC uses QMP PHY with version v8 for PCIe Gen3 x2, but requires
a completely unique qserdes-txrx register offsets compared to existing v8
offsets.

Hence, add a dedicated header file containing the FULL SET of qserdes-txrx
register definitions required for Kaanapali's PCIe PHY operation.

Link:https://lore.kernel.org/all/[email protected]/
Signed-off-by: Jingyi Wang <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>

Kaanapali SoC uses QMP phy with version v8 for PCIe Gen3 x2. Add the new
PCS PCIE specific offsets in a dedicated header file.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Jingyi Wang <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>

Some qserdes-com register offsets for the v8 PHY were previously omitted,
as they were not needed by earlier v8 PHY initialization sequences. Add
these missing v8 register offsets now required to support PCIe QMP PHY on
Kaanapali platform.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Jingyi Wang <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>

Add QMP PCIe PHY support for the Kaanapali platform.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Jingyi Wang <[email protected]>
Reviewed-by: Abel Vesa <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>

Devicetree schema allows the PERST# GPIO to be present in all PCIe bridge
nodes, not just in Root Port node. But the current logic parses PERST# only
from the Root Port nodes. Though it is not causing any issue on the current
platforms, the upcoming platforms will have PERST# in PCIe switch
downstream ports also. So this requires parsing all the PCIe bridge nodes
for the PERST# GPIO.

Hence, rework the parsing logic to extend to all PCIe bridge nodes starting
from the Root Port node. If the 'reset-gpios' property is found for a PCI
bridge node, the GPIO descriptor will be stored in qcom_pcie_perst::desc
and added to the qcom_pcie_port::perst list.

It should be noted that if more than one bridge node has the same GPIO for
PERST# (shared PERST#), the driver will error out. This is due to the
limitation in the GPIOLIB subsystem that allows only exclusive (non-shared)
access to GPIOs from consumers. But this is soon going to get fixed. Once
that happens, it will get incorporated in this driver.

So for now, PERST# sharing is not supported.

Link: https://lore.kernel.org/all/[email protected]/
Tested-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>

…acks

To allow the pwrctrl core to control the power on/off sequences of the
pwrctrl drivers, add the 'struct pci_pwrctrl::power_{on/off}' callbacks and
populate them in the respective pwrctrl drivers.

The pwrctrl drivers still power on the resources on their own now. So there
is no functional change.

Link: https://lore.kernel.org/all/[email protected]/
Co-developed-by: Krishna Chaitanya Chundru <[email protected]>
Signed-off-by: Krishna Chaitanya Chundru <[email protected]>
Tested-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>

…g pwrctrl devices

Previously, the PCI core created pwrctrl devices during pci_scan_device()
on its own and then skipped enumeration of those devices, hoping the
pwrctrl driver would power them on and trigger a bus rescan.

This approach works for endpoint devices directly connected to Root Ports,
but it fails for PCIe switches acting as bus extenders. When the switch
requires pwrctrl support, and the pwrctrl driver is not available during
the pwrctrl device creation, it's enumeration will be skipped during the
initial PCI bus scan.

This premature scan leads the PCI core to allocate resources (bridge
windows, bus numbers) for the upstream bridge based on available downstream
buses at scan time. For non-hotplug capable bridges, PCI core typically
allocates resources based on the number of buses available during the
initial bus scan, which happens to be just one if the switch is not powered
on and enumerated at that time. When the switch gets enumerated later on,
it will fail due to the lack of upstream resources.

As a result, a PCIe switch powered on by the pwrctrl driver cannot be
reliably enumerated currently. Either the switch has to be enabled in the
bootloader or the switch pwrctrl driver has to be loaded during the pwrctrl
device creation time to workaround these issues.

This commit introduces new APIs to explicitly create and destroy pwrctrl
devices from controller drivers by recursively scanning the PCI child nodes
of the controller. These APIs allow creating pwrctrl devices based on the
original criteria and are intended to be called during controller probe and
removal.

These APIs, together with the upcoming APIs for power on/off will allow the
controller drivers to power on all the devices before starting the initial
bus scan, thereby solving the resource allocation issue.

Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Krishna Chaitanya Chundru <[email protected]>
[mani: splitted the patch, cleaned up the code, and rewrote description]
Tested-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>

To fix PCIe bridge resource allocation issues when powering PCIe
switches with the pwrctrl driver, introduce APIs to explicitly power
on and off all related devices simultaneously.

Previously, the individual pwrctrl drivers powered on/off the PCIe devices
autonomously, without any control from the controller drivers. But to
enforce ordering w.r.t powering on the devices, these APIs will power
on/off all the devices at the same time.

The pci_pwrctrl_power_on_devices() API recursively scans the PCI child
nodes, makes sure that pwrctrl drivers are bind to devices, and calls their
power_on() callbacks.

Similarly, pci_pwrctrl_power_off_devices() API powers off devices
recursively via their power_off() callbacks.

These APIs are expected to be called during the controller probe and
suspend/resume time to power on/off the devices. But before calling these
APIs, the pwrctrl devices should've been created beforehand using the
pci_pwrctrl_{create/destroy}_devices() APIs.

Link: https://lore.kernel.org/all/[email protected]/
Co-developed-by: Krishna Chaitanya Chundru <[email protected]>
Signed-off-by: Krishna Chaitanya Chundru <[email protected]>
Tested-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>

Adopt the recently introduced pwrctrl APIs to create, power on, destroy,
and power off pwrctrl devices. In qcom_pcie_host_init(), call
pci_pwrctrl_create_devices() to create devices, then
pci_pwrctrl_power_on_devices() to power them on, both after controller
resource initialization. Once successful, deassert PERST# for all devices.

In qcom_pcie_host_deinit(), call pci_pwrctrl_power_off_devices() after
asserting PERST#. Note that pci_pwrctrl_destroy_devices() is not called
here, as deinit is only invoked during system suspend where device
destruction is unnecessary. If the driver becomes removable in future,
pci_pwrctrl_destroy_devices() should be called in the remove() handler.

At last, remove the old pwrctrl framework code from the PCI core, as the
new APIs are now the sole consumer of pwrctrl functionality. And also do
not power on the pwrctrl drivers during probe() as this is now handled by
the APIs.

Link: https://lore.kernel.org/all/[email protected]/
Co-developed-by: Krishna Chaitanya Chundru <[email protected]>
Signed-off-by: Krishna Chaitanya Chundru <[email protected]>
Tested-by: Chen-Yu Tsai <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>