> -----Original Message----- > From: Peter Ujfalusi [mailto:peter.ujfalusi@xxxxxxxxx] > Sent: Wednesday, October 13, 2010 2:02 PM > To: Varadarajan, Charulatha > Cc: linux-omap@xxxxxxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; > Kamat, Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, > Liam; jhnikula@xxxxxxxxx; > broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx; 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: > > 1. 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. > > > 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? 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 > -- 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
