FROMLIST: PCI/pwrctrl: Major rework to integrate pwrctrl devices with controller drivers #207
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… consistency
Previously the pwrseq, tc9563, and slot pwrctrl drivers used different
naming conventions for their private data structs and pointers to them,
which makes patches hard to read:
Previous names New names
------------------------------------ ----------------------------------
struct pci_pwrctrl_pwrseq_data { struct pci_pwrctrl_pwrseq {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_pwrseq_data *data struct pci_pwrctrl_pwrseq *pwrseq
struct tc9563_pwrctrl_ctx { struct pci_pwrctrl_tc9563 {
struct tc9563_pwrctrl_ctx *ctx struct pci_pwrctrl_tc9563 *tc9563
struct pci_pwrctrl_slot_data { struct pci_pwrctrl_slot {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_slot_data *slot struct pci_pwrctrl_slot *slot
Rename "struct pci_pwrctrl_pwrseq_data" to "pci_pwrctrl_pwrseq".
Rename the "struct pci_pwrctrl ctx" member to "struct pci_pwrctrl pwrctrl".
Rename pointers from "struct pci_pwrctrl_pwrseq_data *data" to
"struct pci_pwrctrl_pwrseq *pwrseq".
No functional change intended.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
…onsistency
Previously the pwrseq, tc9563, and slot pwrctrl drivers used different
naming conventions for their private data structs and pointers to them,
which makes patches hard to read:
Previous names New names
------------------------------------ ----------------------------------
struct pci_pwrctrl_pwrseq_data { struct pci_pwrctrl_pwrseq {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_pwrseq_data *data struct pci_pwrctrl_pwrseq *pwrseq
struct tc9563_pwrctrl_ctx { struct pci_pwrctrl_tc9563 {
struct tc9563_pwrctrl_ctx *ctx struct pci_pwrctrl_tc9563 *tc9563
struct pci_pwrctrl_slot_data { struct pci_pwrctrl_slot {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_slot_data *slot struct pci_pwrctrl_slot *slot
Rename "struct pci_pwrctrl_slot_data" to "struct pci_pwrctrl_slot".
Rename the "struct pci_pwrctrl ctx" member to "struct pci_pwrctrl pwrctrl".
No functional change intended.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
…apter() The API comment for of_find_i2c_adapter_by_node() recommends using put_device() to drop the reference count of I2C adapter instead of using i2c_put_adapter(). So replace i2c_put_adapter() with put_device(). Link: https://lore.kernel.org/all/[email protected]/ Fixes: 4c9c7be ("PCI: pwrctrl: Add power control driver for TC9563") Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]>
Most of pci-pwrctrl-tc9563.c fits in 80 columns. Wrap lines that are gratuitously longer. Whitespace changes only. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]>
Add local struct device * and struct device_node * variables to reduce repetitive pointer chasing. No functional changes intended. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]>
… consistency
Previously the pwrseq, tc9563, and slot pwrctrl drivers used different
naming conventions for their private data structs and pointers to them,
which makes patches hard to read:
Previous names New names
------------------------------------ ----------------------------------
struct pci_pwrctrl_pwrseq_data { struct pci_pwrctrl_pwrseq {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_pwrseq_data *data struct pci_pwrctrl_pwrseq *pwrseq
struct tc9563_pwrctrl_ctx { struct pci_pwrctrl_tc9563 {
struct tc9563_pwrctrl_ctx *ctx struct pci_pwrctrl_tc9563 *tc9563
struct pci_pwrctrl_slot_data { struct pci_pwrctrl_slot {
struct pci_pwrctrl ctx; struct pci_pwrctrl pwrctrl;
struct pci_pwrctrl_slot_data *slot struct pci_pwrctrl_slot *slot
Rename "struct tc9563_pwrctrl_ctx" to "pci_pwrctrl_tc9563".
Move the struct pci_pwrctrl member to be the first element in struct
pci_pwrctrl_tc9563, as it is in the other drivers.
Rename pointers from "struct tc9563_pwrctrl_ctx *ctx" to
"struct pci_pwrctrl_tc9563 *tc9563".
No functional change intended.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
In order to allow the pwrctrl core to control the power on/off logic of the
pwrctrl slot driver, move the power on/off code to
pci_pwrctrl_slot_power_{off/on} helper functions.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Manivannan Sadhasivam <[email protected]>
In order to allow the pwrctrl core to control the power on/off logic of the
pwrctrl pwrseq driver, move the power on/off code to
pci_pwrctrl_pwrseq_power_{off/on} helper functions.
Link: https://lore.kernel.org/all/[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]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
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, its 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 work around these issues. Introduce 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] Reviewed-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]>
To fix bridge resource allocation issues when powering PCI bridges 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 PCI devices
autonomously, without any control from the controller drivers. But to
enforce ordering with respect to 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 bound to devices, and calls
their power_on() callbacks. If any pwrctrl driver is not bound, it will
return -EPROBE_DEFER.
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 be created 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]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
[bhelgaas: return early when !pdev and unindent, move ctx.power_on/off here]
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Chen-Yu Tsai <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
…y APIs Adopt pwrctrl APIs to create, power on/off, and destroy 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. Remove the old pwrctrl framework code from the PCI core (including devlinks) 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]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PCI/pwrctrl: Major rework to integrate pwrctrl devices with controller drivers