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

[Suman Anna]

Hi Tony,

On 08/22/2017 12:37 PM, Tony Lindgren wrote:
> * Suman Anna <s-anna at ti.com> [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