Hi Tony, On 08/22/2017 12:37 PM, Tony Lindgren wrote: > * Suman Anna <s-anna@xxxxxx> [170821 16:48]: >> >> A shutdown sequence follows a reverse pattern >> with the processors put into reset first followed by the unmapping and >> disabling of the MMUs. Both the processors and the MMUs are present >> within a single clock domain and requires the domain be clocked and >> enabled until the last entity. The kernel crash can happen during the >> unmapping phase of the MMUs, as the hwmod layer disables the module >> during the omap_device_idle processing of the processor hwmod. This >> issue is fixed by not defining a modulemode for the IPU/DSP processors, >> which results in keeping the module in an activated state. The module >> is disabled properly during the omap_device_idle processing of the MMU >> hwmod while disabling the MMU. > > I think a better way to fix this would be to make sure the module > is enabled during the unmapping phase of the MMUs. If there is no > driver left at that point to call pm_runtime_get() on the module, > do it via pdata-quirks.c using struct iommu_platform_data? The problem is because there is no reference counting on modulemode programming unlike clocks or omap_device pm_domain callbacks. The IOMMU driver already has an active pm_runtime_get() invoked earlier and invoking another wouldn't result in any change. > If you can't add the enable/disable around existing assert_reset/ > deassert_reset, you can add a new one. The remoteproc driver is only dealing with its resets and hwmod while the IOMMU driver is dealing with its dedicated reset. The PRCM registers though are a single set between the two. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
