From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755788AbaBGNB4 (ORCPT ); Fri, 7 Feb 2014 08:01:56 -0500 Received: from eu1sys200aog118.obsmtp.com ([207.126.144.145]:60435 "EHLO eu1sys200aog118.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752926AbaBGNBx (ORCPT ); Fri, 7 Feb 2014 08:01:53 -0500 Message-ID: <52F4D76F.8070301@st.com> Date: Fri, 7 Feb 2014 12:54:07 +0000 From: srinivas kandagatla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Philipp Zabel Cc: , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Rob Landley , Russell King , Stuart Menefy , Grant Likely , , , , , Arnd Bergmann , , Olof Johansson Subject: Re: [PATCH v2 0/6] ARM: STi reset controller support References: <1389696613-19683-1-git-send-email-srinivas.kandagatla@st.com> <1391437665-11913-1-git-send-email-srinivas.kandagatla@st.com> <1391592486.11239.4.camel@pizza.hi.pengutronix.de> In-Reply-To: <1391592486.11239.4.camel@pizza.hi.pengutronix.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.65.51.147] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Philipp, Thankyou for looking at the patches. On 05/02/14 09:28, Philipp Zabel wrote: > Hi Srinivas, > ... > > the patchset looks good to me for the soft resets. But for the powerdown > bits I am wondering whether the reset controller API is the right > abstraction. Depending on whether those bits really just put the IPs > into reset or there is some power gating / sequencing involved, > shouldn't this rather be handled as a set of pm domains? The hardware name of these control signals into the devices is slightly unfortunate and a bit misleading. We do not generally have separate power domains for peripheral devices in our current STB SoCs, in the sense that the voltage cannot actually be removed from individual devices. In the USB case we believe the powerdown signals internally gate off two of the three incoming clocks to most of the USB controller's logic blocks, essentially holding the device in a disabled (enable/disable might have been a better name for the signal) state. The primary requirement to manipulate these signals is to bring the device out of its cold boot default powerdown/disabled/reset (whatever you want to call it) state when the device is probed or after a SoC wide power loss when resuming from PM_SUSPEND_MEM. > I see that for example on STiH415 there are both soft resets and > powerdown bits for USB[012]. Our IPs typically have two or sometimes three signals going into them, controlled from outside of the IP block itself (typically using SoC global system configuration registers) that you could view as "reset-a-like"; that is toggling each of the signals puts the IP into a state where it is in some way unusable and then back to being useable again. The reset controller API appeared to be the natural abstraction for the drivers to be given access to such control signals, regardless of the precise effect the signals have on the device's internal state. With regards to sequencing between these signals; it is the case that there is a likely sequencing because at least in the USB case it is thought that the "powerdown" stops the clock going to the reset chain logic. But we did not see that as an issue as the reset controller framework allows for multiple named "reset" lines being defined for a device through its DT attributes. The driver knows which signal is which and what each does, because it asks for them by name; therefore, it knows how to impose any required ordering when changing the state of those signals. Thanks, srini From mboxrd@z Thu Jan 1 00:00:00 1970 From: srinivas kandagatla Subject: Re: [PATCH v2 0/6] ARM: STi reset controller support Date: Fri, 7 Feb 2014 12:54:07 +0000 Message-ID: <52F4D76F.8070301@st.com> References: <1389696613-19683-1-git-send-email-srinivas.kandagatla@st.com> <1391437665-11913-1-git-send-email-srinivas.kandagatla@st.com> <1391592486.11239.4.camel@pizza.hi.pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1391592486.11239.4.camel@pizza.hi.pengutronix.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Philipp Zabel Cc: Mark Rutland , devicetree@vger.kernel.org, Russell King , kernel@stlinux.com, Pawel Moll , Ian Campbell , Olof Johansson , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, stephen.gallimore@st.com, Stuart Menefy , Rob Herring , Arnd Bergmann , Rob Landley , Kumar Gala , Grant Likely , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org Hi Philipp, Thankyou for looking at the patches. On 05/02/14 09:28, Philipp Zabel wrote: > Hi Srinivas, > ... > > the patchset looks good to me for the soft resets. But for the powerdown > bits I am wondering whether the reset controller API is the right > abstraction. Depending on whether those bits really just put the IPs > into reset or there is some power gating / sequencing involved, > shouldn't this rather be handled as a set of pm domains? The hardware name of these control signals into the devices is slightly unfortunate and a bit misleading. We do not generally have separate power domains for peripheral devices in our current STB SoCs, in the sense that the voltage cannot actually be removed from individual devices. In the USB case we believe the powerdown signals internally gate off two of the three incoming clocks to most of the USB controller's logic blocks, essentially holding the device in a disabled (enable/disable might have been a better name for the signal) state. The primary requirement to manipulate these signals is to bring the device out of its cold boot default powerdown/disabled/reset (whatever you want to call it) state when the device is probed or after a SoC wide power loss when resuming from PM_SUSPEND_MEM. > I see that for example on STiH415 there are both soft resets and > powerdown bits for USB[012]. Our IPs typically have two or sometimes three signals going into them, controlled from outside of the IP block itself (typically using SoC global system configuration registers) that you could view as "reset-a-like"; that is toggling each of the signals puts the IP into a state where it is in some way unusable and then back to being useable again. The reset controller API appeared to be the natural abstraction for the drivers to be given access to such control signals, regardless of the precise effect the signals have on the device's internal state. With regards to sequencing between these signals; it is the case that there is a likely sequencing because at least in the USB case it is thought that the "powerdown" stops the clock going to the reset chain logic. But we did not see that as an issue as the reset controller framework allows for multiple named "reset" lines being defined for a device through its DT attributes. The driver knows which signal is which and what each does, because it asks for them by name; therefore, it knows how to impose any required ordering when changing the state of those signals. Thanks, srini From mboxrd@z Thu Jan 1 00:00:00 1970 From: srinivas.kandagatla@st.com (srinivas kandagatla) Date: Fri, 7 Feb 2014 12:54:07 +0000 Subject: [PATCH v2 0/6] ARM: STi reset controller support In-Reply-To: <1391592486.11239.4.camel@pizza.hi.pengutronix.de> References: <1389696613-19683-1-git-send-email-srinivas.kandagatla@st.com> <1391437665-11913-1-git-send-email-srinivas.kandagatla@st.com> <1391592486.11239.4.camel@pizza.hi.pengutronix.de> Message-ID: <52F4D76F.8070301@st.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Philipp, Thankyou for looking at the patches. On 05/02/14 09:28, Philipp Zabel wrote: > Hi Srinivas, > ... > > the patchset looks good to me for the soft resets. But for the powerdown > bits I am wondering whether the reset controller API is the right > abstraction. Depending on whether those bits really just put the IPs > into reset or there is some power gating / sequencing involved, > shouldn't this rather be handled as a set of pm domains? The hardware name of these control signals into the devices is slightly unfortunate and a bit misleading. We do not generally have separate power domains for peripheral devices in our current STB SoCs, in the sense that the voltage cannot actually be removed from individual devices. In the USB case we believe the powerdown signals internally gate off two of the three incoming clocks to most of the USB controller's logic blocks, essentially holding the device in a disabled (enable/disable might have been a better name for the signal) state. The primary requirement to manipulate these signals is to bring the device out of its cold boot default powerdown/disabled/reset (whatever you want to call it) state when the device is probed or after a SoC wide power loss when resuming from PM_SUSPEND_MEM. > I see that for example on STiH415 there are both soft resets and > powerdown bits for USB[012]. Our IPs typically have two or sometimes three signals going into them, controlled from outside of the IP block itself (typically using SoC global system configuration registers) that you could view as "reset-a-like"; that is toggling each of the signals puts the IP into a state where it is in some way unusable and then back to being useable again. The reset controller API appeared to be the natural abstraction for the drivers to be given access to such control signals, regardless of the precise effect the signals have on the device's internal state. With regards to sequencing between these signals; it is the case that there is a likely sequencing because at least in the USB case it is thought that the "powerdown" stops the clock going to the reset chain logic. But we did not see that as an issue as the reset controller framework allows for multiple named "reset" lines being defined for a device through its DT attributes. The driver knows which signal is which and what each does, because it asks for them by name; therefore, it knows how to impose any required ordering when changing the state of those signals. Thanks, srini