[alsa-devel] [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

[Peter Ujfalusi]

Hello,

On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:
> 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
> on OMAP2.
> 
> 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.
> (or)
> b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
> [1]
> 
> 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
> series.

it is true that at the moment only audio is using the McBSP ports, but McBSP is 
really flexible, it can run for example in SPI mode, and it can be configured to 
use other serial protocols.
I would go with option c.
Since ASoC is moving to multi-component (the conversion is already in linux-
next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are 
platform drivers.
So if the plat-omap/mcbsp would register the platform device for McBSP clients 
(we have only ASoC client at the moment), and use platform data to pass the 
needed information to the McBSP client driver, than we do not need new API.
We still need to modify the ASoC drivers to make use of this platform data, but 
at least we are going to keep the door open for others to use the McBSP ports 
for other than audio.

> 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.

Sounds fair enough.
 
> 3. Autoidle needs to be disabled for sidetone before enabling the sidetone
> feature. There was a design proposed by Kishon [2] 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
> runtime?

Yeah, this is really annoying problem. The McBSP ST should block autoidle from 
McBSP side, but it does not.
If you can not get through the proposed API, we should consider to switch the 
corresponding McBSP port to NoIdle, when the ST is in use (and restore the idle 
mode, when the ST has been disabled).
When McBSP is in NoIdle the interface clock is not going to be gated, so ST 
block will be running without a problem (ST needs the iface clock for operation)

What do you think?
> 
> [1] https://patchwork.kernel.org/patch/225582/
> [2] https://patchwork.kernel.org/patch/134371/
> 
> We would resend the same patch series by including alsa mailing list
> (alsa-devel at alsa-project.org)
> 
> <<snip>>

-- 
Péter