> -----Original Message----- > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Tuesday, November 17, 2009 2:46 AM > To: Aggarwal, Anuj > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] OMAP: Exporting functions doing common register > access > > Hello Anuj, > > On Mon, 16 Nov 2009, Anuj Aggarwal wrote: > > > These functions need to be exported so that drivers (e.g. McBSP) can > > be configured as modules. > > > > McBSP driver gets built as a module when ASoC driver for OMAP3 EVM > > is configured as module. McBSP driver uses functions like > > omap_ctrl_readl/omap_ctrl_writel, which are defined in control.c > > file but not exported. Without that, McBSP driver fails to build as > > a module. > > > > Signed-off-by: Anuj Aggarwal <anuj.aggarwal@xxxxxx> > > This will prevent the McBSP driver from being usable across chips. For > example, if a future OMAP comes out with McBSP clock source switching > implemented in a different way, or if a DaVinci chip comes out with a > McBSP block but no SCM block, this either won't build or won't run. > > A better approach would be to move the OMAP2/3-specific functions from the > McBSP driver into the OMAP McBSP integration code, > arch/arm/*omap*/mcbsp.c, and to define function pointers in > struct platform_data for these functions, and to pass them from the > integration code into the device driver code. That will make these > drivers independent of chip integration details. Sorry to confuse you, I was talking about the platform specific ASoC-McBSP code for OMAP (file - sound/soc/omap/omap-mcbsp.c) platform. The McBSP driver - both platform and machine specific - doesn't use the functions exported by the patch. Including alsa-devel list too... > > > - Paul -- 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
