[lkml]   [2016]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset

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.

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

 \ /
  Last update: 2016-02-10 07:21    [W:0.089 / U:3.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site