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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
