From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933005AbcBIRl1 (ORCPT ); Tue, 9 Feb 2016 12:41:27 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:36757 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932578AbcBIRlV (ORCPT ); Tue, 9 Feb 2016 12:41:21 -0500 Subject: Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset To: Paul Walmsley References: <1452780672-14339-1-git-send-email-kishon@ti.com> <1452780672-14339-4-git-send-email-kishon@ti.com> <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com> <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com> <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com> <56B900E9.9040306@ti.com> CC: Kishon Vijay Abraham I , Tony Lindgren , Bjorn Helgaas , , Russell King , , , , From: Suman Anna Message-ID: <56BA2495.9020407@ti.com> Date: Tue, 9 Feb 2016 11:40:37 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, 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. regards Suman [1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=a7db749a8a0fdfe7baa185db9f5071789a889061