[alsa-devel] [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
charu at ti.com
Wed Oct 6 09:01:28 CEST 2010
> -----Original Message-----
> From: ABRAHAM, KISHON VIJAY
> Sent: Tuesday, October 05, 2010 10:08 PM
> To: linux-omap at vger.kernel.org
> Cc: Kamat, Nishant; Varadarajan, Charulatha; ABRAHAM, KISHON
> VIJAY; Datta, Shubhrajyoti; Basak, Partha
> Subject: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for
> 2xxx devices
This patch series is targeted to implement mcbsp driver in
hwmod way and to make use of pm_runtime APIs.
This patch series is tested on OMAP3 & 4 and yet to be tested
There are few clarifications required so that the next patch series
can be implemented after aligning.
1. Audio layer is making use of mcbsp and it's dma base addresses and
is closely coupled with omap-mcbsp.
This can be handled either by
a. providing an API with which Audio layer can get these addresses.
b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
Option (a) would only be a workaround to handle the situation. As
audio is the only user for mcbsp, option (b) is better. If option(b)
is agreed upon, the same can be addressed on top of the mcbsp hwmod
2. Sidetone feature is available only in OMAP3 (McBSP2&3) which has
different base address and sys configs compared to it's mcbsp port.
Hence the mcbsp is considered as a single device with two hwmods
for McBSP2&3 devices in OMAP3.
3. Autoidle needs to be disabled for sidetone before enabling the sidetone
feature. There was a design proposed by Kishon  to add an API in hwmod
to modify the autoidle bit but was not agreed upon. How do we handle this
situation where the device has to disable or enable the autoidle bit at
We would resend the same patch series by including alsa mailing list
(alsa-devel at alsa-project.org)
More information about the Alsa-devel