[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

Hi Tony,

On 08/22/2017 12:37 PM, Tony Lindgren wrote:

* Suman Anna [off-list ref] [170821 16:48]:

quoted

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