-----Original Message----- From: Peter Ujfalusi [mailto:peter.ujfalusi@nokia.com] Sent: Wednesday, October 13, 2010 2:02 PM To: Varadarajan, Charulatha Cc: linux-omap@vger.kernel.org; alsa-devel@alsa-project.org; Kamat, Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam; jhnikula@gmail.com; broonie@opensource.wolfsonmicro.com; ABRAHAM, KISHON VIJAY Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices
Hi,
On Friday 08 October 2010 09:20:19 ext Varadarajan, Charulatha wrote:
Sorry I am confused.
With hwmod implementation, there is a device register code for mcbsp devices in mach-omap2/mcbsp.c and a probe in
plat-omap/mcbsp.c. The base
address, dma info are not part of pdata and are available
to the driver
only after probe. I do not understand how the
multi-component design in
ASOC can avoid the new API.
Also with this multi-component approach in ASOC, two device registrations happens for a single mcbsp device with two different rames ("omap-mcbsp-dai.id" & "omap-mcbsp.id"). Please
explain if this
what is expected?
I have given myself some time to think this over...
Thanks Peter.
I think the best way forward is to provide an API from plat-omap/mcbsp.c for client drivers (like ASoC audio) to ask for the needed configuration (the things that is 'hard wired' in soc/omap/omap-mcbsp.c at the monent). Something like omap-mcbsp-get-config(id, &config);
Agreed.
In this way we can keep the door open for other uses of McBSP if ever needed.
Okay.
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.
Agreed. But the current omap-mcbsp driver cannot work standalone for OMAP3/4 due to the issues stated below:
- omap_mcbsp_pollwrite and omap_mcbsp_pollread functions
access McBSP
registers as 16-bit. But in OMAP3/4, McBSP registers
(DRR_REG and DXR_REG)
are limited to 32-bit data accesses and hence poll mode
would not work [x].
Yes, this need to be fixed, but it can be done later, it does not need to be part of the hwmod series.
Okay.
- DMA transfers would also not work as it requires a patch
similar to [y].
Well, this patch was sent in 2008. nowdays we moved the OMAP audio support to ASoC, and there are no 'legacy' ALSA arm/omap drivers anymore. In ASoC the cpu_dai and the platform drivers are separate things. This allows us to use the same platform driver (omap-pcm) for McBSp, McPDM (and in theory we could have OMAP2 EAC) cpu_dai drivers without duplicating code. As a note: most of the features this patch was trying to implement is already done for the ASoC implementation, but if there is need for new features, it has to be done using the ASoC framework.
If we do this, would it not contradict the idea of keeping the door open for others to use the McBSP ports?
If other users should be allowed to use McBSP ports, it is good to have DMA support in plat-omap/mcbsp.c itself and modify the asoc implementation to take advantage of the proposed new mcbsp design. If agreed, this shall be addressed later. Please let me know your thoughts on this.
Coming back to the original question. Either we need to fix
the broken
legacy mcbsp driver or move the omap-mcbsp driver completely to asoc layer. What do you say?
I would keep the partitioning same as it is now.
Okay.
If there is a reason we can add bus driver functionality to McBSP,
Can you elaborate? mcbsp driver is already following platform bus device model.
but at the moment there is no need for that.
For testing any changes in mcbsp driver (including hwmod), we are relying on internal patches (dma/pollmode patches). Instead, if mcbsp dma support is available in the driver itself, it would be useful for bug fixing/development activities.
-- Péter