From mboxrd@z Thu Jan 1 00:00:00 1970 From: lee.jones@linaro.org (Lee Jones) Date: Thu, 25 Oct 2012 10:44:58 +0100 Subject: [PATCH 2/6] pinctrl: Update clock handling for the pinctrl-nomadik GPIO driver In-Reply-To: References: <1351089926-32161-1-git-send-email-lee.jones@linaro.org> <1351089926-32161-3-git-send-email-lee.jones@linaro.org> <20121025073127.GB971@gmail.com> <5088F0EE.8030900@stericsson.com> <20121025082341.GC3348@gmail.com> Message-ID: <20121025094458.GB4008@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 25 Oct 2012, Ulf Hansson wrote: > On 25 October 2012 10:23, Lee Jones wrote: > > On Thu, 25 Oct 2012, Linus Walleij wrote: > > > >> On 10/25/2012 09:31 AM, Lee Jones wrote: > >> > > >> >This certainly doesn't fix the bug we spoke about. I believe Ulf > >> >is still working on that one. > >> > > >> >So do you want me to remove this patch? > >> > > >> > >> Yeah drop it for now. > > > > Actually, a quick question before I do: > > > > If it's better/faster to prepare the clock and keep it prepared > > while you do clk_enable/clk_disable, why don't we do that in all > > drivers? Why do we bother to prepare/unprepare each time if all > > it does is take up cycles? > > > > Depending on clock type, a clk_disable is actually not going to "gate" > the clock, that might happen only in unprepare. This depends on if the > clock is a fast or slow clock. > To save as much power as possible, in general, we should do both > disable and unprepare. Although it will be device driver dependent > were it is most convenient to do this things. > Sometimes it is possible to group them sometimes not. And in this case, it's better to ... ? -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog