On Tue, Dec 14, 2010 at 05:17:28PM -0700, Paul Walmsley wrote: > Hello Omar > > On Mon, 13 Dec 2010, Ramirez Luna, Omar wrote: > > > On Mon, Dec 13, 2010 at 2:12 AM, Cousson, Benoit <b-cousson@xxxxxx> wrote: > > > On 12/11/2010 12:45 AM, Ramirez Luna, Omar wrote: > > >> > > >> Make the parameter received by omap_device_get_mpu_rt_va > > >> consistent with the functions meant to be called by drivers. > > >> > > >> Also move its header declaration to appear in the set of > > >> functions to be used by drivers, as per the comment there. > > > > > > Please note that even if Paul submitted this API upon request from Santosh, > > > we do not want driver to us it most of the time. > > > > Oh, ok. Yes, I was under the impression that this ioremap was internal > > to hwmod, and drivers should do their own one but then I noticed that > > API and since it was under the "public functions through struct > > platform data", I thought it was easier to pass pdev than od. > > > > > All drivers should us the generic Linux way to get physical mem resource and > > > then ioremap it. > > > > Then I guess this function belongs to the "public for core code" and > > not for drivers along with the omap_device_get_pwrdm. > > > > > I assume that if you want to update this API, you are probably already using > > > it. > > > Why cannot you use the generic way? > > > > I can leave the generic way along with ioremap, the purpose was to use > > omap_device APIs as much as possible. > > The above isn't quite it. What I'd suggest you do in your code is this: > > - In your driver-to-core-OMAP integration code in arch/arm/*omap*, call > omap_hwmod_get_mpu_rt_va(), and pass that to the driver via an entry in > the struct platform_data. > > - In your driver code in drivers/*, test to see if that struct > platform_data entry is NULL. If it is, only then should your driver > ioremap(). Otherwise, it should use the address from the struct > platform_data. > > This is because it's not guaranteed that ioremap() on OMAP will continue > to reuse the current static mapping in the future. We've heard from some > mobile OS vendors that they are under significant address space > constraints, so on those distributions it might make sense to only map > devices that are actually in use, and take the additional TLB entry cost. > > Does this make sense? No it doesn't - this is not a valid reason to bugger about with drivers to make them non-standard. omap_ioremap() can be improved to retain its re-use of static mappings by having some kind of tree structure or something like that - ioremap is after all not a performance critical path. There's no need to start passing virtual addresses to drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
