On Wed, Jul 18, 2018 at 6:13 PM, Robin Murphy <robin.murphy@xxxxxxx> wrote: > On 18/07/18 10:30, Vivek Gautam wrote: >> >> On Wed, Jul 11, 2018 at 3:23 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> >> wrote: >>> >>> On Sunday, July 8, 2018 7:34:12 PM CEST Vivek Gautam wrote: >>>> >>>> From: Sricharan R <sricharan@xxxxxxxxxxxxxx> >>>> >>>> Finally add the device link between the master device and >>>> smmu, so that the smmu gets runtime enabled/disabled only when the >>>> master needs it. This is done from add_device callback which gets >>>> called once when the master is added to the smmu. >>>> >>>> Signed-off-by: Sricharan R <sricharan@xxxxxxxxxxxxxx> >>>> Signed-off-by: Vivek Gautam <vivek.gautam@xxxxxxxxxxxxxx> >>>> Reviewed-by: Tomasz Figa <tfiga@xxxxxxxxxxxx> >>>> Cc: Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> >>>> Cc: Lukas Wunner <lukas@xxxxxxxxx> >>>> --- >>>> >>>> - Change since v11 >>>> * Replaced DL_FLAG_AUTOREMOVE flag with DL_FLAG_AUTOREMOVE_SUPPLIER. >>>> >>>> drivers/iommu/arm-smmu.c | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >>>> index 09265e206e2d..916cde4954d2 100644 >>>> --- a/drivers/iommu/arm-smmu.c >>>> +++ b/drivers/iommu/arm-smmu.c >>>> @@ -1461,8 +1461,20 @@ static int arm_smmu_add_device(struct device >>>> *dev) >>>> >>>> iommu_device_link(&smmu->iommu, dev); >>>> >>>> + if (pm_runtime_enabled(smmu->dev) && >>> >>> >>> Why does the creation of the link depend on whether or not runtime PM >>> is enabled for the MMU device? >>> >>> What about system-wide PM and system shutdown? Are they always >>> guaranteed >>> to happen in the right order without the link? >> >> >> Hi Robin, >> >> As Rafael pointed, we should the device link creation should not depend on >> runtime PM being enabled or not, as we would also want to guarantee >> that system wide PM callbacks are called in the right order for smmu >> and clients. >> >> Does this change of removing the check for pm_runtime_enabled() from here >> looks okay to you? > > > FWIW the existing system PM ops make no claim to be perfect, and I wouldn't > be at all surprised if it was only by coincidence that my devices happened > to put on the relevant lists in the right order to start with. If we no > longer need to worry about explicit device_link housekeeping in the SMMU > driver, then creating them unconditionally sounds like the sensible thing to > do. I'd be inclined to treat failure as non-fatal like we do for the sysfs > link, though, since it's another thing that correct SMMU operation doesn't > actually depend on (at this point we don't necessarily know if this consumer > even has a driver at all). Thanks. I will then respin the patch taking care of treating failure as non-fatal. >> FYI, as discussed in the first patch [1] of this series, I will add a >> system wide >> suspend callback - arm_smmu_pm_suspend, that would do clock disable, and >> will >> add corresponding clock enable calls in arm_smmu_pm_resume(). > > > OK, I still don't really understand the finer points of how system PM and > runtime PM interact, but if making it robust is just a case of calling the > runtime suspend/resume hooks as appropriate from the system ones, that > sounds reasonable. Sure. Thanks. Best regards Vivek > > Robin. > >> >> [1] https://lore.kernel.org/patchwork/patch/960460/ >> >> >> Best regards >> Vivek >> >>> >>>> + !device_link_add(dev, smmu->dev, >>>> + DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER)) >>>> { >>>> + dev_err(smmu->dev, "Unable to add link to the consumer >>>> %s\n", >>>> + dev_name(dev)); >>>> + ret = -ENODEV; >>>> + goto out_unlink; >>>> + } >>>> + >>>> return 0; >>>> >>>> +out_unlink: >>>> + iommu_device_unlink(&smmu->iommu, dev); >>>> + arm_smmu_master_free_smes(fwspec); >>>> out_cfg_free: >>>> kfree(cfg); >>>> out_free: >>>> >>> >>> >> >> >> > _______________________________________________ > iommu mailing list > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx > 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
