On Tue, Jan 24, 2012 at 4:44 AM, Sujit Reddy Thumma <sthumma@xxxxxxxxxxxxxx> wrote: > Hi Linus Walleij, > > > On 12/30/2011 7:44 AM, Linus Walleij wrote: >> >> On Mon, Dec 12, 2011 at 9:21 AM, Sujit Reddy Thumma >> <sthumma@xxxxxxxxxxxxxx> wrote: >> >>> Ensure clocks are always enabled before any interaction with the >>> host controller driver. This makes sure that there is no race >>> between host execution and the core layer turning off clocks >>> in different context with clock gating framework. >>> >>> Signed-off-by: Sujit Reddy Thumma<sthumma@xxxxxxxxxxxxxx> >> >> >> I guess Per Förlin may not be available, but would have preferred to >> have his view on this as well, since he knows the semantics of >> pre/post-req. > > > I have checked the implementation for pre-req and post-req in mmc host > drivers. There is no interaction to the controller or card registers in > these functions, but in future if drivers appeal to configure their > controller in these functions then we must have clocks enabled. > > Per, if you are available can you comment on this? > I just got back from 2 months of leave so I apologize for not being up to date. It makes sense to ensure clocking in pre-req() and post-req() implemented by this patch. My only concern from a throughput point of view is if the clocking adds an overhead, but AFAIK the clocking doesn't add an overhead (that would increase the prepare time). Currently the pre-req() and post-req() only prepares DMA for next transfer without interacting with the controller. The intention is to increase throughput by minimizing start latency for the next transfer. It's perfectly ok to do other useful preparations in these hooks as well. The hooks are generic. It should be possible to do clock dependent stuff in these hooks too, it's up to the host driver to do what's best. Acked-by: Per Forlin <per.forlin@xxxxxxxxxxxxxx> Thanks, Per -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
