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