If the vendor drivers can detect the Link up event using mechanisms
such as Link up IRQ and can the driver can enumerate downstream devices
instead of waiting here, then waiting for Link up during probe is not
needed here, which optimizes the boot time.
So skip waiting for link to be up if the driver supports 'linkup_irq'.
Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++--
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 3e41865c7290..26418873ce14 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -530,8 +530,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
goto err_remove_edma;
}
- /* Ignore errors, the link may come up later */
- dw_pcie_wait_for_link(pci);
+ /*
+ * Note: The link up delay is skipped only when a link up IRQ is present.
+ * This flag should not be used to bypass the link up delay for arbitrary
+ * reasons.
+ */
+ if (!pp->linkup_irq)
+ /* Ignore errors, the link may come up later */
+ dw_pcie_wait_for_link(pci);
bridge->sysdata = pp;
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 347ab74ac35a..539c6d106bb0 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -379,6 +379,7 @@ struct dw_pcie_rp {
bool use_atu_msg;
int msg_atu_index;
struct resource *msg_res;
+ bool linkup_irq;
};
struct dw_pcie_ep_ops {
--
2.34.1
On Fri, Nov 01, 2024 at 05:04:12PM GMT, Krishna chaitanya chundru wrote: > If the vendor drivers can detect the Link up event using mechanisms > such as Link up IRQ and can the driver can enumerate downstream devices > instead of waiting here, then waiting for Link up during probe is not > needed here, which optimizes the boot time. > > So skip waiting for link to be up if the driver supports 'linkup_irq'. > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> > --- > drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++-- > drivers/pci/controller/dwc/pcie-designware.h | 1 + > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c > index 3e41865c7290..26418873ce14 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > @@ -530,8 +530,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) > goto err_remove_edma; > } > > - /* Ignore errors, the link may come up later */ > - dw_pcie_wait_for_link(pci); > + /* > + * Note: The link up delay is skipped only when a link up IRQ is present. > + * This flag should not be used to bypass the link up delay for arbitrary > + * reasons. Perhaps by improving the naming of the variable, you don't need 3 lines of comment describing the conditional. > + */ > + if (!pp->linkup_irq) > + /* Ignore errors, the link may come up later */ Does this mean that we will be able to start handling these errors? > + dw_pcie_wait_for_link(pci); > > bridge->sysdata = pp; > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > index 347ab74ac35a..539c6d106bb0 100644 > --- a/drivers/pci/controller/dwc/pcie-designware.h > +++ b/drivers/pci/controller/dwc/pcie-designware.h > @@ -379,6 +379,7 @@ struct dw_pcie_rp { > bool use_atu_msg; > int msg_atu_index; > struct resource *msg_res; > + bool linkup_irq; Please name this for what it is, rather than some property from which some other decision should be derived. (And then you need a comment to describe how people should interpret and use it) Also, "linkup_irq" sound like an int carrying the interrupt number, not a boolean. Please call it "use_async_linkup", "use_linkup_irq" or something. Regards, Bjorn > }; > > struct dw_pcie_ep_ops { > > -- > 2.34.1 > >
On Fri, Nov 01, 2024 at 10:26:38AM -0500, Bjorn Andersson wrote: > On Fri, Nov 01, 2024 at 05:04:12PM GMT, Krishna chaitanya chundru wrote: > > If the vendor drivers can detect the Link up event using mechanisms > > such as Link up IRQ and can the driver can enumerate downstream devices > > instead of waiting here, then waiting for Link up during probe is not > > needed here, which optimizes the boot time. > > > > So skip waiting for link to be up if the driver supports 'linkup_irq'. > > > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> > > --- > > drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++-- > > drivers/pci/controller/dwc/pcie-designware.h | 1 + > > 2 files changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c > > index 3e41865c7290..26418873ce14 100644 > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > > @@ -530,8 +530,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) > > goto err_remove_edma; > > } > > > > - /* Ignore errors, the link may come up later */ > > - dw_pcie_wait_for_link(pci); > > + /* > > + * Note: The link up delay is skipped only when a link up IRQ is present. > > + * This flag should not be used to bypass the link up delay for arbitrary > > + * reasons. > > Perhaps by improving the naming of the variable, you don't need 3 lines > of comment describing the conditional. > > > + */ > > + if (!pp->linkup_irq) > > + /* Ignore errors, the link may come up later */ > > Does this mean that we will be able to start handling these errors? > > > + dw_pcie_wait_for_link(pci); > > > > bridge->sysdata = pp; > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > > index 347ab74ac35a..539c6d106bb0 100644 > > --- a/drivers/pci/controller/dwc/pcie-designware.h > > +++ b/drivers/pci/controller/dwc/pcie-designware.h > > @@ -379,6 +379,7 @@ struct dw_pcie_rp { > > bool use_atu_msg; > > int msg_atu_index; > > struct resource *msg_res; > > + bool linkup_irq; > > Please name this for what it is, rather than some property from which > some other decision should be derived. (And then you need a comment to > describe how people should interpret and use it) > > Also, "linkup_irq" sound like an int carrying the interrupt number, not > a boolean. > > > Please call it "use_async_linkup", "use_linkup_irq" or something. > "use_linkup_irq" sounds good to me. But I do like to keep the note above as there were incidents that people tried to avoid this delay as a "workaround" to unrelated problems. - Mani -- மணிவண்ணன் சதாசிவம்
On 11/1/2024 8:56 PM, Bjorn Andersson wrote: > On Fri, Nov 01, 2024 at 05:04:12PM GMT, Krishna chaitanya chundru wrote: >> If the vendor drivers can detect the Link up event using mechanisms >> such as Link up IRQ and can the driver can enumerate downstream devices >> instead of waiting here, then waiting for Link up during probe is not >> needed here, which optimizes the boot time. >> >> So skip waiting for link to be up if the driver supports 'linkup_irq'. >> >> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> >> --- >> drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++-- >> drivers/pci/controller/dwc/pcie-designware.h | 1 + >> 2 files changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c >> index 3e41865c7290..26418873ce14 100644 >> --- a/drivers/pci/controller/dwc/pcie-designware-host.c >> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c >> @@ -530,8 +530,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) >> goto err_remove_edma; >> } >> >> - /* Ignore errors, the link may come up later */ >> - dw_pcie_wait_for_link(pci); >> + /* >> + * Note: The link up delay is skipped only when a link up IRQ is present. >> + * This flag should not be used to bypass the link up delay for arbitrary >> + * reasons. > > Perhaps by improving the naming of the variable, you don't need 3 lines > of comment describing the conditional. > These comments are added so that no one will misuse this flag in the future which was happened previously. >> + */ >> + if (!pp->linkup_irq) >> + /* Ignore errors, the link may come up later */ > > Does this mean that we will be able to start handling these errors? we haven't changed anything here it was present from long ago, the reason why driver is not considering the return value is for some platforms the link may come up later and the driver doesn't want to fail here. > >> + dw_pcie_wait_for_link(pci); >> >> bridge->sysdata = pp; >> >> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h >> index 347ab74ac35a..539c6d106bb0 100644 >> --- a/drivers/pci/controller/dwc/pcie-designware.h >> +++ b/drivers/pci/controller/dwc/pcie-designware.h >> @@ -379,6 +379,7 @@ struct dw_pcie_rp { >> bool use_atu_msg; >> int msg_atu_index; >> struct resource *msg_res; >> + bool linkup_irq; > > Please name this for what it is, rather than some property from which > some other decision should be derived. (And then you need a comment to > describe how people should interpret and use it) > > Also, "linkup_irq" sound like an int carrying the interrupt number, not > a boolean. > > > Please call it "use_async_linkup", "use_linkup_irq" or something. > ack will change it to "use_linkup_irq" - Krishna Chaitanya. > Regards, > Bjorn > >> }; >> >> struct dw_pcie_ep_ops { >> >> -- >> 2.34.1 >> >>
© 2016 - 2024 Red Hat, Inc.