[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 07:12 AM, Suman Anna wrote:
> Hi Paul,
> On 02/09/2016 01:36 PM, 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?
>> Also - would that address the potential issue that you mentioned with the
>> PCIe block, or is that a different issue?
> Yeah, I think that would address the PCIe block issue in terms of reset
> state balancing between pm_runtime_get_sync() and pm_runtime_put()
> calls. Right now, they are unbalanced. The PCIe block is using these
> only in probe and remove, so it should work for that IP.

As I mentioned before this would result in undesired behavior during
suspend/resume cycle in PCIe. (This should be okay for the current mainline
code but would break once we add suspend/resume support for PCIe).


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