[PATCH] OMAP: omap_device: use pdev as parameter to get rt_va

[Russell King - ARM Linux]

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 at ti.com> 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.