OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c
authorPaul Walmsley <paul@pwsan.com>
Fri, 8 Oct 2010 17:40:19 +0000 (11:40 -0600)
committerPaul Walmsley <paul@pwsan.com>
Fri, 8 Oct 2010 17:40:19 +0000 (11:40 -0600)
commitcf4c87abe238ec17cd0255b4e21abd949d7f811e
treefeffd8e664e1718ab4dc0d4ba83c26fe5b8d4be3
parent829e5b127a33d3baa227e87636032f36cd4c05fc
OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c

The OMAP ASoC McBSP code implemented CLKR and FSR signal muxing via
direct System Control Module writes on OMAP2+.  This required the
omap_ctrl_{read,write}l() functions to be exported, which is against
policy: the only code that should call those functions directly is
OMAP core code, not device drivers.  omap_ctrl_{read,write}*() are no
longer exported, so the driver no longer builds as a module.

Fix the pinmuxing part of the problem by removing calls to
omap_ctrl_{read,write}l() from the OMAP ASoC McBSP code and
implementing signal muxing functions in arch/arm/mach-omap2/mcbsp.c.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, these symbols must be exported for use by
sound/soc/omap/omap-mcbsp.c.

Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/*, and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are.  These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversion.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
arch/arm/mach-omap2/mcbsp.c
arch/arm/plat-omap/include/plat/control.h
arch/arm/plat-omap/include/plat/mcbsp.h
arch/arm/plat-omap/mcbsp.c
sound/soc/omap/omap-mcbsp.c