Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset

From: Kishon Vijay Abraham I
Date: Wed Feb 10 2016 - 00:37:40 EST




On Wednesday 10 February 2016 01:06 AM, Paul Walmsley wrote:
> Hi Suman
>
> On Tue, 9 Feb 2016, Suman Anna wrote:
>
>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>
>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>
>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks.
>>>>> Those often need special reset handling to ensure that WFI/HLT-like
>>>>> instructions are executed after reset. This special handling ensures that
>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby
>>>>> to the PRCM - thus allowing power management for the rest of the chip to
>>>>> work correctly.
>>>>>
>>>>> But that doesn't seem to be the case with PCIe - and maybe others -
>>>>> possibly some of the MMUs?
>>>>
>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>
>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.
>>> We've stated that the main point of the custom hardreset code is to handle
>>> processors that need to be placed into WFI/HLT, but it doesn't seem like
>>> there would be an equivalent for MMUs. Thoughts?
>>
>> The current OMAP IOMMU code already leverages the pdata ops for
>> performing the resets, so not adding the flags would also require
>> additional changes in the driver.
>>
>> Also, the reset lines controlling the MMUs actually also manage the
>> reset for all the other sub-modules other than the processor cores
>> within the sub-systems. We have currently different issues (see [1] for
>> eg. around the IPU sub-system entering RET in between), so from a PM
>> point of view, we do prefer to place the MMUs also in reset when we are
>> runtime suspended.
>
> Should we reassert hardreset in _idle() for IP blocks that don't have
> HWMOD_CUSTOM_HARDRESET set on them? Would that allow us to use this
> mechanism for the uncore hardreset lines, or are there other quirks?

IIUC _idle() will be called on pm_runtime_put. That would mean we perform reset
on every suspend/resume cycle which is not desired. (suspend/resume support for
PCIe is not yet in mainline but once we have it runtime_put and runtime_get
will be invoked during suspend/resume cycle). Let me know if my understanding
is wrong.

Thanks
Kishon
>
> Also - would that address the potential issue that you mentioned with the
> PCIe block, or is that a different issue?
>
>
> - Paul
>