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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
