Re: [PATCH v12 2/4] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

From: Rafael J. Wysocki
Date: Wed Jul 11 2018 - 06:59:41 EST


On Wed, Jul 11, 2018 at 12:05 PM, Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
> Hi Rafael,
>
> Thanks for review.
>
> On Wed, Jul 11, 2018 at 6:53 PM Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
>>
>> On Sunday, July 8, 2018 7:34:11 PM CEST Vivek Gautam wrote:
>> > From: Sricharan R <sricharan@xxxxxxxxxxxxxx>
>> >
>> > 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@xxxxxxxxxxxxxx>
>> > [vivek: Cleanup pm runtime calls]
>> > Signed-off-by: Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx>
>> > Reviewed-by: Tomasz Figa <tfiga@xxxxxxxxxxxx>
>> > ---
>> >
>> > - Change since v11
>> > * Replaced pm_runtime_disable() with pm_runtime_force_suspend()
>> > to avoid warning about " Unpreparing enabled clock".
>> > Full warning text mentioned in cover patch.
>> >
>> > drivers/iommu/arm-smmu.c | 92 +++++++++++++++++++++++++++++++++++++++++++-----
>> > 1 file changed, 84 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> > index a01d0dde21dd..09265e206e2d 100644
>> > --- a/drivers/iommu/arm-smmu.c
>> > +++ b/drivers/iommu/arm-smmu.c
>> > @@ -268,6 +268,20 @@ static struct arm_smmu_option_prop arm_smmu_options[] = {
>> > { 0, NULL},
>> > };
>> >
>> > +static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu)
>> > +{
>> > + if (pm_runtime_enabled(smmu->dev))
>>
>> Why do you need the pm_runtime_enabled() checks here and below?
>>
>> pm_runtime_get_sync() and pm_runtime_put() should work just fine if
>> runtime PM is not enabled.
>
> Because pm_runtime_get_sync() acquires a spin lock, even if only for
> the short time of checking if runtime PM is enabled and SMMU driver
> maintainers didn't want any spin locks in certain IOMMU API code paths
> on hardware implementations that don't need runtime PM, while we still
> need to be able to control runtime PM there on hardware
> implementations that need so.

OK, so it is an optimization. It would be good to put a comment in
there to that effect.