[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALLhW=7yJTq_cfB=KGY5VT8fNO1u_hrY118ysihFuQA+gVFRuQ@mail.gmail.com>
Date: Fri, 3 Aug 2012 10:52:09 -0500
From: Omar Ramirez Luna <omar.luna@...aro.org>
To: Vaibhav Hiremath <hvaibhav@...com>, Paul Walmsley <paul@...an.com>
Cc: Benoit Cousson <b-cousson@...com>,
Tony Lindgren <tony@...mide.com>,
Russell King <linux@....linux.org.uk>,
Kevin Hilman <khilman@...com>,
Ohad Ben-Cohen <ohad@...ery.com>,
Tomi Valkeinen <tomi.valkeinen@...com>,
linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] ARM: OMAP: hwmod: revise deassert sequence
On 3 August 2012 00:24, Vaibhav Hiremath <hvaibhav@...com> wrote:
> On 8/3/2012 3:50 AM, Omar Ramirez Luna wrote:
>> So in _enable:
>>
>> _enable_clocks(oh);
>> if (soc_ops.enable_module)
>> soc_ops.enable_module(oh);
>>
>> The enable_module part seems redundant to me, since the module should
>> be already enabled by the first call to _enable_clocks.
>
> Yes they do same thing, I believe the plan is to get rid of all clock
> leaf-nodes in the near future, and let hwmod handle module
> enable/disable part.
If this is the case then an enable_module call is needed in my patch
for when these changes are made. The original works fine but only
because currently clock framework does what enable_module is doing.
Paul,
Please let me know if you want me to resend with this change.
Regards,
Omar
--
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