Date:   Thu, 30 Aug 2018 19:29:46 +0530
From:   Vivek Gautam <vivek.gautam@...eaurora.org>
To:     Tomasz Figa <tfiga@...omium.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, alex.williamson@...hat.com,
        Linux PM <linux-pm@...r.kernel.org>, sboyd@...nel.org,
        freedreno <freedreno@...ts.freedesktop.org>,
        Will Deacon <will.deacon@....com>,
        open list <linux-kernel@...r.kernel.org>,
        "list@....net:IOMMU DRIVERS <iommu@...ts.linux-foundation.org>, Joerg
        Roedel <joro@...tes.org>," <iommu@...ts.linux-foundation.org>,
        "robh+dt" <robh+dt@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Andy Gross <andy.gross@...aro.org>,
        Robin Murphy <robin.murphy@....com>
Subject: Re: [Patch v15 2/5] iommu/arm-smmu: Invoke pm_runtime during probe,
 add/remove device

On Thu, Aug 30, 2018 at 3:04 PM Tomasz Figa <tfiga@...omium.org> wrote:
>
> On Thu, Aug 30, 2018 at 6:22 PM Vivek Gautam
> <vivek.gautam@...eaurora.org> wrote:
> >
> > On Mon, Aug 27, 2018 at 4:27 PM Vivek Gautam
> > <vivek.gautam@...eaurora.org> wrote:
> > >
> > > From: Sricharan R <sricharan@...eaurora.org>
> > >
> > > The smmu device probe/remove and add/remove master device callbacks
> > > gets called when the smmu is not linked to its master, that is without
> > > the context of the master device. So calling runtime apis in those places
> > > separately.
> > >
> > > Signed-off-by: Sricharan R <sricharan@...eaurora.org>
> > > [vivek: Cleanup pm runtime calls]
> > > Signed-off-by: Vivek Gautam <vivek.gautam@...eaurora.org>
> > > Reviewed-by: Tomasz Figa <tfiga@...omium.org>
> > > Tested-by: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
> > > ---
> > >
> > > Changes since v14:
> > >  - none.
> > >
> > >  drivers/iommu/arm-smmu.c | 101 +++++++++++++++++++++++++++++++++++++++++++----
> > >  1 file changed, 93 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > index a81224bc6637..23b4a60149b6 100644
> > > --- a/drivers/iommu/arm-smmu.c
> > > +++ b/drivers/iommu/arm-smmu.c
> >
> > [snip]
> >
> > > @@ -2131,6 +2188,26 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> > >         if (err)
> > >                 return err;
> > >
> > > +       /*
> > > +        * We want to avoid touching dev->power.lock in fastpaths unless
> > > +        * it's really going to do something useful - pm_runtime_enabled()
> > > +        * can serve as an ideal proxy for that decision. So, conditionally
> > > +        * enable pm_runtime.
> > > +        */
> > > +       if (dev->pm_domain)
> > > +               pm_runtime_enable(dev);
> > > +
> > > +       err = arm_smmu_rpm_get(smmu);
> >
> > We shouldn't be doing a runtime_get() yet, as this eventually calls
> > arm_smmu_device_reset().
> > arm_smmu_device_reset() should be called only after arm_smmu_device_cfg_probe().
> > So, I plan to replace the pm_runtime_get/put() calls in probe() with
> > simple clk_bulk_enable()
> > to let the driver initialize smmu, and at the end of the probe we can
> > disable the clocks and
> > enable runtime pm over the device to let it take care of the device further-on.
> >
>
> We can avoid the explicit clock disable by just calling
> pm_runtime_set_active() before pm_runtime_enable(), assuming that what
> probe does is symmetrical with the suspend callback, which would be
> called after the latter.

Sure, that sounds reasonable. Will use pm_runtime_set_active() instead
of explicitly disabling the clocks.Thanks.

Best regards
Vivek

>
> Best regards,
> Tomasz
> _______________________________________________
> iommu mailing list
> iommu@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists