[alsa-devel] [PATCH] OMAP: Exporting functions doing common register access

[Aggarwal, Anuj]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Tuesday, November 17, 2009 2:46 AM
> To: Aggarwal, Anuj
> Cc: linux-omap at vger.kernel.org
> 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 at ti.com>
> 
> 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