On Mon, Nov 26, 2012 at 09:57:45PM +0530, Viresh Kumar wrote:
> On 20 November 2012 14:17, Dmitry Torokhov wrote:
> > No, not really, it just does not work well with devm_* patches that got
> > applied: on removal you unprepare clock as the very first operation and
> > then devm_* does the rest wh
On 20 November 2012 14:17, Dmitry Torokhov wrote:
> No, not really, it just does not work well with devm_* patches that got
> applied: on removal you unprepare clock as the very first operation and
> then devm_* does the rest which is wrong order.
>
> I am looking at adding dem_* for clocks.
I ha
On 20 November 2012 14:17, Dmitry Torokhov wrote:
> No, not really, it just does not work well with devm_* patches that got
> applied: on removal you unprepare clock as the very first operation and
> then devm_* does the rest which is wrong order.
Nice. I don't expect the order would do anything
On Tue, Nov 20, 2012 at 01:26:29PM +0530, Viresh Kumar wrote:
> On 12 November 2012 11:27, Viresh Kumar wrote:
> > On 8 November 2012 19:10, Viresh Kumar wrote:
> >> From: Vipul Kumar Samar
> >>
> >> clk_{un}prepare is mandatory for platforms using common clock framework.
> >> Because
> >> for
On 12 November 2012 11:27, Viresh Kumar wrote:
> On 8 November 2012 19:10, Viresh Kumar wrote:
>> From: Vipul Kumar Samar
>>
>> clk_{un}prepare is mandatory for platforms using common clock framework.
>> Because
>> for SPEAr we don't do anything in clk_{un}prepare() calls, just call them
>> on
On 8 November 2012 19:10, Viresh Kumar wrote:
> From: Vipul Kumar Samar
>
> clk_{un}prepare is mandatory for platforms using common clock framework.
> Because
> for SPEAr we don't do anything in clk_{un}prepare() calls, just call them ones
> in probe/remove.
>
> Signed-off-by: Vipul Kumar Samar
6 matches
Mail list logo
