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 -- 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
