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

From: Paul Walmsley
Date: Tue Feb 09 2016 - 14:36:51 EST


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?


- Paul