Hi Suman, On Friday 12 February 2016 02:13 AM, Suman Anna wrote: > On 02/09/2016 11:38 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >> 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). > > Yeah, I was wondering if some peripheral would want only the clock to be > controlled during _idle() and not reset. Even then for the PCIe case > that you are talking about, going through a pm_runtime_get_sync(), > pm_runtime_put_sync()/pm_runtime_put() deasserts the resets everytime right. But it'll deassert a line which is already deasserted. So it actually doesn't do a reset again. > _enable() is called. Right now, the code block has ignored the return > value from the _hardreset_deassert(), but if you check it and bail out, > then your get_sync() would start failing from the second invocation. hmm.. yeah. > > Can you elaborate more on what kind of issues you will see on > suspend/resume cycle with PCIe? Do note that _idle() gets called through At this point there are other issues w.r.t suspend/resume in PCI-dra7xx but as such reset of the controller is not desired during suspend/resume cycle and it'll result in the register contents being reset (haven't tested it though). Thanks Kishon -- 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
