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
_______________________________________________
--
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
