| Message ID | 20190125232616.25714-1-bjorn.andersson@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
| Series | PCI: qcom: Don't deassert reset GPIO during probe | expand |
Hi Bjorn, Thanks for the patch! On 1/26/19 1:26 AM, Bjorn Andersson wrote: > Acquiring the reset GPIO low means that reset is being deasserted, this > is followed almost immediately with qcom_pcie_host_init() asserting it, > initializing it and then finally deasserting it again, for the link to > come up. > > Some PCIe devices requires a minimum time between the initial deassert > and subsequent reset cycles. In a platform that boots with the reset > GPIO asserted this requirement is being violated by this deassert/assert > pulse. > > Acquiring the reset GPIO high will prevent this by matching the state to > the subsequent asserted state. > > Cc: stable@vger.kernel.org > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > --- > drivers/pci/controller/dwc/pcie-qcom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index d185ea5fe996..a7f703556790 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > @@ -1228,7 +1228,7 @@ static int qcom_pcie_probe(struct platform_device *pdev) > > pcie->ops = of_device_get_match_data(dev); > > - pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); > + pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH); > if (IS_ERR(pcie->reset)) { > ret = PTR_ERR(pcie->reset); > goto err_pm_runtime_put; > Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
On Fri, Jan 25, 2019 at 03:26:16PM -0800, Bjorn Andersson wrote: > Acquiring the reset GPIO low means that reset is being deasserted, this > is followed almost immediately with qcom_pcie_host_init() asserting it, > initializing it and then finally deasserting it again, for the link to > come up. > > Some PCIe devices requires a minimum time between the initial deassert > and subsequent reset cycles. In a platform that boots with the reset > GPIO asserted this requirement is being violated by this deassert/assert > pulse. > > Acquiring the reset GPIO high will prevent this by matching the state to > the subsequent asserted state. > > Cc: stable@vger.kernel.org Missing Fixes: tag, please provide me one so that I can proceed. Lorenzo > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > --- > drivers/pci/controller/dwc/pcie-qcom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index d185ea5fe996..a7f703556790 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > @@ -1228,7 +1228,7 @@ static int qcom_pcie_probe(struct platform_device *pdev) > > pcie->ops = of_device_get_match_data(dev); > > - pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); > + pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH); > if (IS_ERR(pcie->reset)) { > ret = PTR_ERR(pcie->reset); > goto err_pm_runtime_put; > -- > 2.18.0 >
On Wed 13 Feb 07:23 PST 2019, Lorenzo Pieralisi wrote: > On Fri, Jan 25, 2019 at 03:26:16PM -0800, Bjorn Andersson wrote: > > Acquiring the reset GPIO low means that reset is being deasserted, this > > is followed almost immediately with qcom_pcie_host_init() asserting it, > > initializing it and then finally deasserting it again, for the link to > > come up. > > > > Some PCIe devices requires a minimum time between the initial deassert > > and subsequent reset cycles. In a platform that boots with the reset > > GPIO asserted this requirement is being violated by this deassert/assert > > pulse. > > > > Acquiring the reset GPIO high will prevent this by matching the state to > > the subsequent asserted state. > > > > Cc: stable@vger.kernel.org > > Missing Fixes: tag, please provide me one so that I can proceed. > This applies to the original commit introducing this driver, so: Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Regards, Bjorn
On Mon, Feb 18, 2019 at 09:16:03PM -0800, Bjorn Andersson wrote: > On Wed 13 Feb 07:23 PST 2019, Lorenzo Pieralisi wrote: > > > On Fri, Jan 25, 2019 at 03:26:16PM -0800, Bjorn Andersson wrote: > > > Acquiring the reset GPIO low means that reset is being deasserted, this > > > is followed almost immediately with qcom_pcie_host_init() asserting it, > > > initializing it and then finally deasserting it again, for the link to > > > come up. > > > > > > Some PCIe devices requires a minimum time between the initial deassert > > > and subsequent reset cycles. In a platform that boots with the reset > > > GPIO asserted this requirement is being violated by this deassert/assert > > > pulse. > > > > > > Acquiring the reset GPIO high will prevent this by matching the state to > > > the subsequent asserted state. > > > > > > Cc: stable@vger.kernel.org > > > > Missing Fixes: tag, please provide me one so that I can proceed. > > > > This applies to the original commit introducing this driver, so: > > Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Applied to pci/dwc for v5.1, thanks. Lorenzo
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index d185ea5fe996..a7f703556790 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1228,7 +1228,7 @@ static int qcom_pcie_probe(struct platform_device *pdev) pcie->ops = of_device_get_match_data(dev); - pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); + pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH); if (IS_ERR(pcie->reset)) { ret = PTR_ERR(pcie->reset); goto err_pm_runtime_put;
Acquiring the reset GPIO low means that reset is being deasserted, this is followed almost immediately with qcom_pcie_host_init() asserting it, initializing it and then finally deasserting it again, for the link to come up. Some PCIe devices requires a minimum time between the initial deassert and subsequent reset cycles. In a platform that boots with the reset GPIO asserted this requirement is being violated by this deassert/assert pulse. Acquiring the reset GPIO high will prevent this by matching the state to the subsequent asserted state. Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> --- drivers/pci/controller/dwc/pcie-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)