From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Fernandes Subject: Re: [PATCH v5] ARM: omap: edma: add suspend suspend/resume hooks Date: Fri, 8 Nov 2013 10:14:30 -0600 Message-ID: <527D0DE6.6090506@ti.com> References: <1383863549-7438-1-git-send-email-zonque@gmail.com> <87siv7pxpp.fsf@linaro.org> <527C6F70.1010103@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Kevin Hilman Cc: Nishanth Menon , balajitk@ti.com, s.neumann@raumfeld.com, Sekhar Nori , Gururaja Hebbar , Daniel Mack , Russ Dill , Vaibhav Bedia , linux-omap , linux-arm-kernel List-Id: linux-omap@vger.kernel.org On 11/08/2013 12:28 AM, Kevin Hilman wrote: [..] >>> Also, I believe it was already suggested by Nishanth, but the late/early >>> callbacks are probably more appropriate here than the noirq callbacks. >>> Unless there's a *really* good reason to use the noirq callbacks, they >>> should be avoided. >>> >>> That being said, I wonder if the whole approach here is the right one. >>> I know you're basing your stuff on some TI tree, but that doesn't make >>> it the right way (usually, it's the opposite, but I digress...) ;) >>> >>> IMO, EDMA should be done like we currently do I2C and not implement >>> suspend/resume at all. Instead, the driver should do runtime PM done on >> >> But a potential problem with this is powering edma on or off between xfers may >> slow things down quite a bit because xfers happen so much often and there is >> some overhead in the pm_runtime calls which adds up overtime when dealing with >> something as frequent as EDMA. Also we would lose the global EDMA context right >> so we'd have to restore the context every time during runtime PM (?). > > Have a look at the autosuspend feature of runtime PM. (c.f. > Documentation/power/pm_runtime.txt) Sure, will do that. Thanks :) Just one more silly question, in very frequent operations is there no over-head even when using autosuspend? Because when I traced last time (without autosuspend), the depth of pm runtime calls were quite a lot but this could also be because of the OMAP implementation. >> I had a patch that also made AES driver not pm_runtime_get/put specially when >> the next crypto request was imminent. But instead adopted a softer approach >> where the pm_runtime_put call would happen at a time when we are sure we're at >> the end of all requests. This resulted in quite a speed up. > > Sounds like you partially re-invented autosuspend. Hehe. :) regards, -Joel From mboxrd@z Thu Jan 1 00:00:00 1970 From: joelf@ti.com (Joel Fernandes) Date: Fri, 8 Nov 2013 10:14:30 -0600 Subject: [PATCH v5] ARM: omap: edma: add suspend suspend/resume hooks In-Reply-To: References: <1383863549-7438-1-git-send-email-zonque@gmail.com> <87siv7pxpp.fsf@linaro.org> <527C6F70.1010103@ti.com> Message-ID: <527D0DE6.6090506@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 11/08/2013 12:28 AM, Kevin Hilman wrote: [..] >>> Also, I believe it was already suggested by Nishanth, but the late/early >>> callbacks are probably more appropriate here than the noirq callbacks. >>> Unless there's a *really* good reason to use the noirq callbacks, they >>> should be avoided. >>> >>> That being said, I wonder if the whole approach here is the right one. >>> I know you're basing your stuff on some TI tree, but that doesn't make >>> it the right way (usually, it's the opposite, but I digress...) ;) >>> >>> IMO, EDMA should be done like we currently do I2C and not implement >>> suspend/resume at all. Instead, the driver should do runtime PM done on >> >> But a potential problem with this is powering edma on or off between xfers may >> slow things down quite a bit because xfers happen so much often and there is >> some overhead in the pm_runtime calls which adds up overtime when dealing with >> something as frequent as EDMA. Also we would lose the global EDMA context right >> so we'd have to restore the context every time during runtime PM (?). > > Have a look at the autosuspend feature of runtime PM. (c.f. > Documentation/power/pm_runtime.txt) Sure, will do that. Thanks :) Just one more silly question, in very frequent operations is there no over-head even when using autosuspend? Because when I traced last time (without autosuspend), the depth of pm runtime calls were quite a lot but this could also be because of the OMAP implementation. >> I had a patch that also made AES driver not pm_runtime_get/put specially when >> the next crypto request was imminent. But instead adopted a softer approach >> where the pm_runtime_put call would happen at a time when we are sure we're at >> the end of all requests. This resulted in quite a speed up. > > Sounds like you partially re-invented autosuspend. Hehe. :) regards, -Joel