| Message ID | 20231124014508.43358-1-kevin.xie@starfivetech.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] PCI: Add PCIE_CONFIG_REQUEST_WAIT_MS waiting time value | expand |
On Fri, Nov 24, 2023 at 09:45:08AM +0800, Kevin Xie wrote: > Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting > time between sending the first configuration request to the device and > exit from a conventional reset (or after link training completes). s/marco/macro/ List the first event before the second one, i.e., the delay is from exit from reset to the config request. > As described in the conventional reset rules of PCI specifications, > there are two different use cases of the value: > > - With a downstream port that supports link speeds <= 5.0 GT/s, > the waiting is following exit from a conventional reset. > > - With a downstream port that supports link speeds > 5.0 GT/s, > the waiting is after link training completes. Include the spec citation here as well as in the comment below. I assume there are follow-on patches that actually use this? Can we make this the first patch in a series so we know we don't have an unused macro lying around? > Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com> > Reviewed-by: Mason Huo <mason.huo@starfivetech.com> > --- > drivers/pci/pci.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > index 5ecbcf041179..4ca8766e546e 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -22,6 +22,13 @@ > */ > #define PCIE_PME_TO_L2_TIMEOUT_US 10000 > > +/* > + * PCIe r6.0, sec 6.6.1, <Conventional Reset> > + * Requires a minimum waiting of 100ms before sending a configuration > + * request to the device. > + */ > +#define PCIE_CONFIG_REQUEST_WAIT_MS 100 > + > extern const unsigned char pcie_link_speed[]; > extern bool pci_early_dump; > > -- > 2.25.1 >
On Fri, Nov 24, 2023 at 09:45:08AM +0800, Kevin Xie wrote: > Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting > time between sending the first configuration request to the device and > exit from a conventional reset (or after link training completes). > > As described in the conventional reset rules of PCI specifications, > there are two different use cases of the value: > > - With a downstream port that supports link speeds <= 5.0 GT/s, > the waiting is following exit from a conventional reset. > > - With a downstream port that supports link speeds > 5.0 GT/s, > the waiting is after link training completes. > > Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com> > Reviewed-by: Mason Huo <mason.huo@starfivetech.com> > --- > drivers/pci/pci.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > index 5ecbcf041179..4ca8766e546e 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -22,6 +22,13 @@ > */ > #define PCIE_PME_TO_L2_TIMEOUT_US 10000 > > +/* > + * PCIe r6.0, sec 6.6.1, <Conventional Reset> > + * Requires a minimum waiting of 100ms before sending a configuration > + * request to the device. > + */ > +#define PCIE_CONFIG_REQUEST_WAIT_MS 100 Oh, and I think this name should include something about "reset" because that's the common scenario and that's the spec section where the value is mentioned.
On 2023/11/30 7:21, Bjorn Helgaas wrote: > On Fri, Nov 24, 2023 at 09:45:08AM +0800, Kevin Xie wrote: >> Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting >> time between sending the first configuration request to the device and >> exit from a conventional reset (or after link training completes). > > s/marco/macro/ > > List the first event before the second one, i.e., the delay is from > exit from reset to the config request. > OK，I will use "from A to B" instead of "between A and B". >> As described in the conventional reset rules of PCI specifications, >> there are two different use cases of the value: >> >> - With a downstream port that supports link speeds <= 5.0 GT/s, >> the waiting is following exit from a conventional reset. >> >> - With a downstream port that supports link speeds > 5.0 GT/s, >> the waiting is after link training completes. > > Include the spec citation here as well as in the comment below. > OK, I will include the spec citation here. > I assume there are follow-on patches that actually use this? Can we > make this the first patch in a series so we know we don't have an > unused macro lying around? > Yes, we will use the marco in the next version of our PCIe controller patches. Here is the link of current version patch series: https://lore.kernel.org/lkml/20231115114912.71448-20-minda.chen@starfivetech.com/T/#u Do you mean that I should put this patch back to the above series as one of the separate patches? Thanks for your review. >> Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com> >> Reviewed-by: Mason Huo <mason.huo@starfivetech.com> >> --- >> drivers/pci/pci.h | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h >> index 5ecbcf041179..4ca8766e546e 100644 >> --- a/drivers/pci/pci.h >> +++ b/drivers/pci/pci.h >> @@ -22,6 +22,13 @@ >> */ >> #define PCIE_PME_TO_L2_TIMEOUT_US 10000 >> >> +/* >> + * PCIe r6.0, sec 6.6.1, <Conventional Reset> >> + * Requires a minimum waiting of 100ms before sending a configuration >> + * request to the device. >> + */ >> +#define PCIE_CONFIG_REQUEST_WAIT_MS 100 >> + >> extern const unsigned char pcie_link_speed[]; >> extern bool pci_early_dump; >> >> -- >> 2.25.1 >>
On 2023/11/30 7:22, Bjorn Helgaas wrote: > On Fri, Nov 24, 2023 at 09:45:08AM +0800, Kevin Xie wrote: >> Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting >> time between sending the first configuration request to the device and >> exit from a conventional reset (or after link training completes). >> >> As described in the conventional reset rules of PCI specifications, >> there are two different use cases of the value: >> >> - With a downstream port that supports link speeds <= 5.0 GT/s, >> the waiting is following exit from a conventional reset. >> >> - With a downstream port that supports link speeds > 5.0 GT/s, >> the waiting is after link training completes. >> >> Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com> >> Reviewed-by: Mason Huo <mason.huo@starfivetech.com> >> --- >> drivers/pci/pci.h | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h >> index 5ecbcf041179..4ca8766e546e 100644 >> --- a/drivers/pci/pci.h >> +++ b/drivers/pci/pci.h >> @@ -22,6 +22,13 @@ >> */ >> #define PCIE_PME_TO_L2_TIMEOUT_US 10000 >> >> +/* >> + * PCIe r6.0, sec 6.6.1, <Conventional Reset> >> + * Requires a minimum waiting of 100ms before sending a configuration >> + * request to the device. >> + */ >> +#define PCIE_CONFIG_REQUEST_WAIT_MS 100 > > Oh, and I think this name should include something about "reset" > because that's the common scenario and that's the spec section where > the value is mentioned. Agree, how about PCIE_RESET_CONFIG_DEVICE_WAIT_MS?
On Thu, Nov 30, 2023 at 06:03:55PM +0800, Kevin Xie wrote: > On 2023/11/30 7:21, Bjorn Helgaas wrote: > > On Fri, Nov 24, 2023 at 09:45:08AM +0800, Kevin Xie wrote: > >> Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting > >> time between sending the first configuration request to the device and > >> exit from a conventional reset (or after link training completes). > > > > s/marco/macro/ > > > > List the first event before the second one, i.e., the delay is from > > exit from reset to the config request. > > OK，I will use "from A to B" instead of "between A and B". That's not my point. My point was you said "between B (config request) and A (exit from reset)". "A" happens first, so it should be mentioned first. > > I assume there are follow-on patches that actually use this? Can we > > make this the first patch in a series so we know we don't have an > > unused macro lying around? > > Yes, we will use the marco in the next version of our PCIe controller patches. > Here is the link of current version patch series: > https://lore.kernel.org/lkml/20231115114912.71448-20-minda.chen@starfivetech.com/T/#u > > Do you mean that I should put this patch back to the above series as > one of the separate patches? Yes, please. Handling them as a group is less overhead and helps avoid merge issues (if they're all in a series there's no possibility that the user gets merged before the macro itself). Bjorn
On 2023/12/1 2:35, Bjorn Helgaas wrote: > On Thu, Nov 30, 2023 at 06:03:55PM +0800, Kevin Xie wrote: >> On 2023/11/30 7:21, Bjorn Helgaas wrote: >> > On Fri, Nov 24, 2023 at 09:45:08AM +0800, Kevin Xie wrote: >> >> Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting >> >> time between sending the first configuration request to the device and >> >> exit from a conventional reset (or after link training completes). >> > >> > s/marco/macro/ >> > >> > List the first event before the second one, i.e., the delay is from >> > exit from reset to the config request. >> >> OK，I will use "from A to B" instead of "between A and B". > > That's not my point. > > My point was you said "between B (config request) and A (exit from > reset)". "A" happens first, so it should be mentioned first. > Got it. >> > I assume there are follow-on patches that actually use this? Can we >> > make this the first patch in a series so we know we don't have an >> > unused macro lying around? >> >> Yes, we will use the marco in the next version of our PCIe controller patches. >> Here is the link of current version patch series: >> https://lore.kernel.org/lkml/20231115114912.71448-20-minda.chen@starfivetech.com/T/#u >> >> Do you mean that I should put this patch back to the above series as >> one of the separate patches? > > Yes, please. Handling them as a group is less overhead and helps > avoid merge issues (if they're all in a series there's no possibility > that the user gets merged before the macro itself). > OK, I will put the patch back with these changes. > Bjorn
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 5ecbcf041179..4ca8766e546e 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -22,6 +22,13 @@ */ #define PCIE_PME_TO_L2_TIMEOUT_US 10000 +/* + * PCIe r6.0, sec 6.6.1, <Conventional Reset> + * Requires a minimum waiting of 100ms before sending a configuration + * request to the device. + */ +#define PCIE_CONFIG_REQUEST_WAIT_MS 100 + extern const unsigned char pcie_link_speed[]; extern bool pci_early_dump;
Add the PCIE_CONFIG_REQUEST_WAIT_MS marco to define the minimum waiting time between sending the first configuration request to the device and exit from a conventional reset (or after link training completes). As described in the conventional reset rules of PCI specifications, there are two different use cases of the value: - With a downstream port that supports link speeds <= 5.0 GT/s, the waiting is following exit from a conventional reset. - With a downstream port that supports link speeds > 5.0 GT/s, the waiting is after link training completes. Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com> Reviewed-by: Mason Huo <mason.huo@starfivetech.com> --- drivers/pci/pci.h | 7 +++++++ 1 file changed, 7 insertions(+)