[PATCH v2 0/6] ARM: STi reset controller support

[maxime.coquelin@st.com (Maxime Coquelin)]

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