Messages in this thread |  | | Date | Wed, 19 Feb 2014 14:57:29 +0100 | From | Maxime Coquelin <> | Subject | Re: [PATCH v2 0/6] ARM: STi reset controller support |
| |
Hi Philipp,
On 02/07/2014 01:54 PM, srinivas kandagatla wrote: > 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. >
Did Srini's explanations convinced you?
If so, could you queue the series for v3.15?
Thanks, Maxime
> > Thanks, > srini > > > _______________________________________________
|  |