On Tue, Jan 16, 2024 at 11:55:17AM +0200, Dmitry Baryshkov wrote:
> On Tue, 16 Jan 2024 at 07:17, Krishna Chaitanya Chundru
> <quic_krichai@xxxxxxxxxxx> wrote:
> >
> >
> >
> > On 1/12/2024 9:03 PM, Dmitry Baryshkov wrote:
> > > On Fri, 12 Jan 2024 at 16:25, Krishna chaitanya chundru
> > > <quic_krichai@xxxxxxxxxxx> wrote:
> > >>
> > >> QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
> > >> maintains hardware state of a regulator by performing max aggregation of
> > >> the requests made by all of the processors.
> > >>
> > >> PCIe controller can operate on different RPMh performance state of power
> > >> domain based up on the speed of the link. And this performance state varies
> > >> from target to target.
> > >>
> > >> It is manadate to scale the performance state based up on the PCIe speed
> > >> link operates so that SoC can run under optimum power conditions.
> > >>
> > >> Add Operating Performance Points(OPP) support to vote for RPMh state based
> > >> upon GEN speed link is operating.
> > >>
> > >> OPP can handle ICC bw voting also, so move icc bw voting through opp
> > >> framework if opp entries are present.
> > >>
> > >> In PCIe certain gen speeds like GEN1x2 & GEN2X1 or GEN3x2 & GEN4x1 use
> > >> same icc bw and has frequency, so use frequency based search to reduce
> > >> number of entries in the opp table.
> > >>
> > >> Don't initialize icc if opp is supported.
> > >>
> > >> Signed-off-by: Krishna chaitanya chundru <quic_krichai@xxxxxxxxxxx>
> > >> ---
> > >> drivers/pci/controller/dwc/pcie-qcom.c | 83 ++++++++++++++++++++++++++++------
> > >> 1 file changed, 70 insertions(+), 13 deletions(-)
> > >>
> > >> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > >> index 035953f0b6d8..31512dc9d6ff 100644
> > >> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > >> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
[...]
> > >> static int qcom_pcie_link_transition_count(struct seq_file *s, void *data)
> > >> @@ -1471,8 +1502,10 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
> > >> static int qcom_pcie_probe(struct platform_device *pdev)
> > >> {
> > >> const struct qcom_pcie_cfg *pcie_cfg;
> > >> + unsigned long max_freq = INT_MAX;
> > >> struct device *dev = &pdev->dev;
> > >> struct qcom_pcie *pcie;
> > >> + struct dev_pm_opp *opp;
> > >> struct dw_pcie_rp *pp;
> > >> struct resource *res;
> > >> struct dw_pcie *pci;
> > >> @@ -1539,9 +1572,33 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> > >> goto err_pm_runtime_put;
> > >> }
> > >>
> > >> - ret = qcom_pcie_icc_init(pcie);
> > >> - if (ret)
> > >> + /* OPP table is optional */
> > >> + ret = devm_pm_opp_of_add_table(dev);
> > >> + if (ret && ret != -ENODEV) {
> > >> + dev_err_probe(dev, ret, "Failed to add OPP table\n");
> > >> goto err_pm_runtime_put;
> > >> + }
> > >
> > > Can we initialise the table from the driver if it is not found? This
> > > will help us by having the common code later on.
> > >
> > we already icc voting if there is no opp table present in the dts.
>
> Yes. So later we have two different code paths: one for the OPP table
> being present and another one for the absent OPP table. My suggestion
> is to initialise minimal OPP table by hand and then have a common code
> path in qcom_pcie_icc_update().
>
Are you suggesting to duplicate DT in the driver?
- Mani
--
மணிவண்ணன் சதாசிவம்
