[PATCH 1/2] OMAP: features: export symbol omap3_features

[Paul Walmsley]

On Fri, 24 Sep 2010, Paul Walmsley wrote:

> On Fri, 24 Sep 2010, Nishanth Menon wrote:
> 
> > The intent of omap_has_featureX() is to ensure that the drivers dont do
> > cpu_is_omap123(). Now if we had OMAP dma driver which has DMA chaining - what
> > options do we have DMA driver?
> > 
> > a) we introduce it based on cpu_is_omap123() -> bad bad nightmare for
> > maintenance
> > b) we introduce it based on module h/w block(TI internal terminology "IP
> > block") revision -> unfortunately no luck in some of the h/w blocks.
> > c) we use if (omap_has_dma_chaining())
> 
> d) you pass in errata/feature flags via a platform_data struct, like 
> McBSP, McSPI, MMC, MUSB, I2C, etc. already do on OMAP.  On OMAP1, which 
> doesn't have hwmod support, you set your platform_data in your OMAP1 
> integration code.  On OMAP2+ (which has hwmod support), you define your 
> errata/feature flags and any other integration data that you need to pass 
> via the struct omap_hwmod.dev_attr field, then pass that data via struct 
> platform_data in the OMAP2+ integration code.

Just to clarify something that may be unclear: there's no problem with 
calling cpu_is_omapXXXX(), or any other OMAP core-specific function, from 
the OMAP<->driver integration code, living in arch/arm/*omap*.  The 
results of those functions can then be passed through platform_data.  But 
there is a problem with calling OMAP core-specific functions directly from 
the driver code itself, since driver code should be completely 
platform-independent -- e.g., the same DMA controller could exist on OMAP, 
DaVinci, etc.


- Paul