| Message ID | 20240223-opp_support-v7-3-10b4363d7e71@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | PCI: qcom: Add support for OPP | expand |
On 23.02.2024 15:48, Krishna chaitanya chundru wrote: > To access PCIe registers, PCIe BAR space, config space the CPU-PCIe > ICC(interconnect consumers) path should be voted otherwise it may > lead to NoC(Network on chip) timeout. We are surviving because of > other driver vote for this path. > As there is less access on this path compared to PCIe to mem path > add minimum vote i.e 1KBps bandwidth always. > > In suspend remove the disable this path after register space access > is done. > > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> > --- [...] > > + /* Remove cpu path vote after all the register access is done */ > + ret = icc_disable(pcie->icc_cpu); > + if (ret) { > + dev_err(dev, "failed to disable icc path of cpu-pcie: %d\n", ret); > + if (pcie->suspended) { > + qcom_pcie_host_init(&pcie->pci->pp); > + pcie->suspended = false; > + } > + qcom_pcie_icc_opp_update(pcie); This doesn't compile (you rename it in patch 6, this is patch 3) Konrad
On 2/24/2024 5:32 AM, Konrad Dybcio wrote: > On 23.02.2024 15:48, Krishna chaitanya chundru wrote: >> To access PCIe registers, PCIe BAR space, config space the CPU-PCIe >> ICC(interconnect consumers) path should be voted otherwise it may >> lead to NoC(Network on chip) timeout. We are surviving because of >> other driver vote for this path. >> As there is less access on this path compared to PCIe to mem path >> add minimum vote i.e 1KBps bandwidth always. >> >> In suspend remove the disable this path after register space access >> is done. >> >> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> >> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com> >> --- > > [...] > >> >> + /* Remove cpu path vote after all the register access is done */ >> + ret = icc_disable(pcie->icc_cpu); >> + if (ret) { >> + dev_err(dev, "failed to disable icc path of cpu-pcie: %d\n", ret); >> + if (pcie->suspended) { >> + qcom_pcie_host_init(&pcie->pci->pp); >> + pcie->suspended = false; >> + } >> + qcom_pcie_icc_opp_update(pcie); > > This doesn't compile (you rename it in patch 6, this is patch 3) > > Konrad > I will fix this in my next series. - Krishna Chaitanya.
On Fri, Feb 23, 2024 at 08:18:00PM +0530, Krishna chaitanya chundru wrote: > To access PCIe registers, PCIe BAR space, config space the CPU-PCIe > ICC(interconnect consumers) path should be voted otherwise it may > lead to NoC(Network on chip) timeout. We are surviving because of > other driver vote for this path. > As there is less access on this path compared to PCIe to mem path > add minimum vote i.e 1KBps bandwidth always. Add blank line between paragraphs or wrap into a single paragraph. Add space before open paren, e.g., "ICC (interconnect consumers)", "NoC (Network on Chip)". > In suspend remove the disable this path after register space access > is done. "... remove the disable this path ..." has too many verbs :) Maybe "When suspending, disable this path ..."? > + * The config space, BAR space and registers goes through cpu-pcie path. > + * Set peak bandwidth to 1KBps as recommended by HW team for this path all the time. Wrap to fit in 80 columns. > + /* Remove cpu path vote after all the register access is done */ One of the other patches has s/cpu/CPU/ in it. Please do the same here. Bjorn
On 2/28/2024 4:52 AM, Bjorn Helgaas wrote: > On Fri, Feb 23, 2024 at 08:18:00PM +0530, Krishna chaitanya chundru wrote: >> To access PCIe registers, PCIe BAR space, config space the CPU-PCIe >> ICC(interconnect consumers) path should be voted otherwise it may >> lead to NoC(Network on chip) timeout. We are surviving because of >> other driver vote for this path. >> As there is less access on this path compared to PCIe to mem path >> add minimum vote i.e 1KBps bandwidth always. > > Add blank line between paragraphs or wrap into a single paragraph. > > Add space before open paren, e.g., "ICC (interconnect consumers)", > "NoC (Network on Chip)". > >> In suspend remove the disable this path after register space access >> is done. > > "... remove the disable this path ..." has too many verbs :) > Maybe "When suspending, disable this path ..."? > >> + * The config space, BAR space and registers goes through cpu-pcie path. >> + * Set peak bandwidth to 1KBps as recommended by HW team for this path all the time. > > Wrap to fit in 80 columns. > >> + /* Remove cpu path vote after all the register access is done */ > > One of the other patches has s/cpu/CPU/ in it. Please do the same > here. > > Bjorn I will update the commit message as suggested in next series. We have limit up to 100 columns in the driver right, I am ok to change to 80 but just checking if I misunderstood something. - Krishna Chaitanya.
On Wed, Feb 28, 2024 at 12:08:37PM +0530, Krishna Chaitanya Chundru wrote: > We have limit up to 100 columns in the driver right, I am ok to change > to 80 but just checking if I misunderstood something. Please take a look at Documentation/process/coding-style.rst, which clearly states: The preferred limit on the length of a single line is 80 columns. Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. So generally you should stay within 80 columns, unless not doing so *significantly* increases readability. (And note that making such decisions requires human judgement, which is why checkpatch now only warns about lines longer than 100 chars.) Johan
On Wed, Feb 28, 2024 at 12:08:37PM +0530, Krishna Chaitanya Chundru wrote: > On 2/28/2024 4:52 AM, Bjorn Helgaas wrote: > > On Fri, Feb 23, 2024 at 08:18:00PM +0530, Krishna chaitanya chundru wrote: > > > To access PCIe registers, PCIe BAR space, config space the CPU-PCIe > > > ICC(interconnect consumers) path should be voted otherwise it may > > > lead to NoC(Network on chip) timeout. We are surviving because of > > > other driver vote for this path. > > > As there is less access on this path compared to PCIe to mem path > > > add minimum vote i.e 1KBps bandwidth always. > > > + * The config space, BAR space and registers goes through cpu-pcie path. > > > + * Set peak bandwidth to 1KBps as recommended by HW team for this path all the time. > > > > Wrap to fit in 80 columns. > We have limit up to 100 columns in the driver right, I am ok to change to 80 > but just checking if I misunderstood something. I should have said "wrap to fit in 80 columns to match the rest of the file." I looked at pcie-qcom.c, and with a few minor exceptions, it fits in 80 columns, and maintaining that consistency makes it easier to browse. Sometimes exceptions make sense for code, but for comments, having some that fit in 80 columns and some that require 100 just makes life harder. Bjorn
On 2/28/2024 8:20 PM, Bjorn Helgaas wrote: > On Wed, Feb 28, 2024 at 12:08:37PM +0530, Krishna Chaitanya Chundru wrote: >> On 2/28/2024 4:52 AM, Bjorn Helgaas wrote: >>> On Fri, Feb 23, 2024 at 08:18:00PM +0530, Krishna chaitanya chundru wrote: >>>> To access PCIe registers, PCIe BAR space, config space the CPU-PCIe >>>> ICC(interconnect consumers) path should be voted otherwise it may >>>> lead to NoC(Network on chip) timeout. We are surviving because of >>>> other driver vote for this path. >>>> As there is less access on this path compared to PCIe to mem path >>>> add minimum vote i.e 1KBps bandwidth always. > >>>> + * The config space, BAR space and registers goes through cpu-pcie path. >>>> + * Set peak bandwidth to 1KBps as recommended by HW team for this path all the time. >>> >>> Wrap to fit in 80 columns. > >> We have limit up to 100 columns in the driver right, I am ok to change to 80 >> but just checking if I misunderstood something. > > I should have said "wrap to fit in 80 columns to match the rest of the > file." I looked at pcie-qcom.c, and with a few minor exceptions, it > fits in 80 columns, and maintaining that consistency makes it easier > to browse. Sometimes exceptions make sense for code, but for > comments, having some that fit in 80 columns and some that require 100 > just makes life harder. > > Bjorn > Sure I will wrap in 80 columns, in my next patch series. - Krishna Chaitanya.
On 2/28/2024 7:09 PM, Johan Hovold wrote: > On Wed, Feb 28, 2024 at 12:08:37PM +0530, Krishna Chaitanya Chundru wrote: > >> We have limit up to 100 columns in the driver right, I am ok to change >> to 80 but just checking if I misunderstood something. > > Please take a look at Documentation/process/coding-style.rst, which > clearly states: > > The preferred limit on the length of a single line is 80 > columns. > > Statements longer than 80 columns should be broken into sensible > chunks, unless exceeding 80 columns significantly increases > readability and does not hide information. > > So generally you should stay within 80 columns, unless not doing so > *significantly* increases readability. (And note that making such > decisions requires human judgement, which is why checkpatch now only > warns about lines longer than 100 chars.) > > Johan ok got it Johan, As checkpatch is not reporting any warnings or errors for I misunderstood this. I will correct the comments to fit in 80 columns in my next series. - Krishna Chaitanya.
On Wed, Feb 28, 2024 at 08:43:53PM +0530, Krishna Chaitanya Chundru wrote: > On 2/28/2024 7:09 PM, Johan Hovold wrote: > > On Wed, Feb 28, 2024 at 12:08:37PM +0530, Krishna Chaitanya Chundru wrote: > > > > > We have limit up to 100 columns in the driver right, I am ok to change > > > to 80 but just checking if I misunderstood something. > > > > Please take a look at Documentation/process/coding-style.rst, which > > clearly states: > > > > The preferred limit on the length of a single line is 80 > > columns. > > > > Statements longer than 80 columns should be broken into sensible > > chunks, unless exceeding 80 columns significantly increases > > readability and does not hide information. > > > > So generally you should stay within 80 columns, unless not doing so > > *significantly* increases readability. (And note that making such > > decisions requires human judgement, which is why checkpatch now only > > warns about lines longer than 100 chars.) > > ok got it Johan, As checkpatch is not reporting any warnings or errors > for I misunderstood this. I will correct the comments to fit in 80 columns > in my next series. Yeah, checkpatch is great and useful, but the bottom line is that it's a tool that helps keep things relatively consistent, and a lot of that consistency just comes down to paying attention to all the surrounding code so the result looks coherent instead of a hodgepodge. Bjorn
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 10f2d0bb86be..088ebd2e5865 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -240,6 +240,7 @@ struct qcom_pcie { struct phy *phy; struct gpio_desc *reset; struct icc_path *icc_mem; + struct icc_path *icc_cpu; const struct qcom_pcie_cfg *cfg; struct dentry *debugfs; bool suspended; @@ -1372,6 +1373,9 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie) if (IS_ERR(pcie->icc_mem)) return PTR_ERR(pcie->icc_mem); + pcie->icc_cpu = devm_of_icc_get(pci->dev, "cpu-pcie"); + if (IS_ERR(pcie->icc_cpu)) + return PTR_ERR(pcie->icc_cpu); /* * Some Qualcomm platforms require interconnect bandwidth constraints * to be set before enabling interconnect clocks. @@ -1381,7 +1385,18 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie) */ ret = icc_set_bw(pcie->icc_mem, 0, QCOM_PCIE_LINK_SPEED_TO_BW(1)); if (ret) { - dev_err(pci->dev, "failed to set interconnect bandwidth: %d\n", + dev_err(pci->dev, "failed to set interconnect bandwidth for pcie-mem: %d\n", + ret); + return ret; + } + + /* + * The config space, BAR space and registers goes through cpu-pcie path. + * Set peak bandwidth to 1KBps as recommended by HW team for this path all the time. + */ + ret = icc_set_bw(pcie->icc_cpu, 0, kBps_to_icc(1)); + if (ret) { + dev_err(pci->dev, "failed to set interconnect bandwidth for cpu-pcie: %d\n", ret); return ret; } @@ -1573,7 +1588,7 @@ static int qcom_pcie_suspend_noirq(struct device *dev) */ ret = icc_set_bw(pcie->icc_mem, 0, kBps_to_icc(1)); if (ret) { - dev_err(dev, "Failed to set interconnect bandwidth: %d\n", ret); + dev_err(dev, "Failed to set interconnect bandwidth for pcie-mem: %d\n", ret); return ret; } @@ -1597,6 +1612,18 @@ static int qcom_pcie_suspend_noirq(struct device *dev) pcie->suspended = true; } + /* Remove cpu path vote after all the register access is done */ + ret = icc_disable(pcie->icc_cpu); + if (ret) { + dev_err(dev, "failed to disable icc path of cpu-pcie: %d\n", ret); + if (pcie->suspended) { + qcom_pcie_host_init(&pcie->pci->pp); + pcie->suspended = false; + } + qcom_pcie_icc_opp_update(pcie); + return ret; + } + return 0; } @@ -1605,6 +1632,12 @@ static int qcom_pcie_resume_noirq(struct device *dev) struct qcom_pcie *pcie = dev_get_drvdata(dev); int ret; + ret = icc_enable(pcie->icc_cpu); + if (ret) { + dev_err(dev, "failed to enable icc path of cpu-pcie: %d\n", ret); + return ret; + } + if (pcie->suspended) { ret = qcom_pcie_host_init(&pcie->pci->pp); if (ret)