On Mon, Jun 09, 2025 at 04:21:23PM +0530, Krishna Chaitanya Chundru wrote:
> If the driver wants to move to higher data rate/speed than the current data
> rate then the controller driver may need to change certain votes so that
> link may come up at requested data rate/speed like QCOM PCIe controllers
> need to change their RPMh (Resource Power Manager-hardened) state. Once
> link retraining is done controller drivers needs to adjust their votes
> based on the final data rate.
>
> Some controllers also may need to update their bandwidth voting like
> ICC BW votings etc.
>
> So, add pre_link_speed_change() & post_link_speed_change() op to call
> before & after the link re-train. There is no explicit locking mechanisms
> as these are called by a single client Endpoint driver.
>
> In case of PCIe switch, if there is a request to change target speed for a
> downstream port then no need to call these function ops as these are
> outside the scope of the controller drivers.
> +++ b/include/linux/pci.h
> @@ -599,6 +599,24 @@ struct pci_host_bridge {
> void (*release_fn)(struct pci_host_bridge *);
> int (*enable_device)(struct pci_host_bridge *bridge, struct pci_dev *dev);
> void (*disable_device)(struct pci_host_bridge *bridge, struct pci_dev *dev);
> + /*
> + * Callback to the host bridge drivers to update ICC BW votes, clock
> + * frequencies etc.. for the link re-train to come up in targeted speed.
> + * These are intended to be called by devices directly attached to the
> + * Root Port. These are called by a single client Endpoint driver, so
> + * there is no need for explicit locking mechanisms.
> + */
> + int (*pre_link_speed_change)(struct pci_host_bridge *bridge,
> + struct pci_dev *dev, int speed);
> + /*
> + * Callback to the host bridge drivers to adjust ICC BW votes, clock
> + * frequencies etc.. to the updated speed after link re-train. These
> + * are intended to be called by devices directly attached to the
> + * Root Port. These are called by a single client Endpoint driver,
> + * so there is no need for explicit locking mechanisms.
No need to repeat the entire comment. s/.././
These pointers feel awfully specific for being in struct
pci_host_bridge, since we only need them for a questionable QCOM
controller. I think this needs to be pushed down into qcom somehow as
some kind of quirk.
> + */
> + void (*post_link_speed_change)(struct pci_host_bridge *bridge,
> + struct pci_dev *dev, int speed);
