On Thursday 14 October 2010 17:51:15 ext Varadarajan, Charulatha wrote: > > Yes, this need to be fixed, but it can be done later, it does > > not need to be > > part of the hwmod series. > > Okay. This problem there for a long time, and so far no one complained, or fixed it. Probably there are no users for pollread/write at all, but I would not remove the functionality. It is better to fix them later. > > > 2. 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? Why? If you add support for different sample formats to ASoC, it will not change anything. > 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. What I mean is that later we could add DMA transfer functionality if there is a need, but at the moment I don't see any reason to do that. Also moving the DMA functionality to plat-omap/mcbsp.c would require quite a big change in there, and as well in the ASoC code. On top of that we will broke the sound/soc/omap/omap-pcm.c to be McBSP independent, and that is one of the main points here. We are using omap-pcm.c with McBSP and McPDM dai drivers. That has to remain the same. In the future we can implement DMA transfer capabilities to mcbsp. I would not do this as part of hwmod either. I think such an extension to the current McBSP code is only needed if/when we have other users for McBSP than audio. > > > 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. I meant adding DMA functionality to McBSP. I would not worry about this at this time. > > > 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. You should use audio (ASoC) for verification, for example Beagle, or other board. I would say that the audio support is solid on OMAP platforms, and that is the main thing which must work after hwmod conversion. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
