Date:	Wed, 19 Feb 2014 14:57:29 +0100
From:	Maxime Coquelin <maxime.coquelin@...com>
To:	srinivas kandagatla <srinivas.kandagatla@...com>,
	Philipp Zabel <p.zabel@...gutronix.de>
Cc:	Mark Rutland <mark.rutland@....com>, <devicetree@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>, <kernel@...inux.com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Olof Johansson <olof@...om.net>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <stephen.gallimore@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Arnd Bergmann <arnd@...db.de>, Rob Landley <rob@...dley.net>,
	Kumar Gala <galak@...eaurora.org>,
	Grant Likely <grant.likely@...aro.org>,
	<linux-arm-kernel@...ts.infradead.org>
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
>
>
> _______________________________________________
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists