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... 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);
In this way we can keep the door open for other uses of McBSP if ever needed.
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.
- 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.
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. If there is a reason we can add bus driver functionality to McBSP, but at the moment there is no need for that.