At Mon, 27 Apr 2009 10:42:10 -0400, Jon Smirl wrote: > > On Mon, Apr 27, 2009 at 10:24 AM, Mark Brown <broonie@xxxxxxxxxxxxx> wrote: > > On Mon, Apr 27, 2009 at 10:16:16AM -0400, Jon Smirl wrote: > >> On Mon, Apr 27, 2009 at 10:05 AM, Mark Brown <broonie@xxxxxxxxxxxxx> wrote: > > > >> > It's a fairly hefty change for -rc4. ?From the sounds of it you just > >> > need to add the constraint? > > > >> it is also broken because of the additional requirement of needing to > >> estimate the current position of the DMA transfer. The changes in > >> pcm_lib.c have made it non-functional. When I went into fix those > >> problems I found a couple more issues. It's ok for i2s to be broken > >> in this release, Grant and I both know it is broken and won't ship > >> anything based on it. > > > > Well, if you don't see any need to fix it then I guess that's OK. We > > should probably disable the Kconfig option for the release in case > > people try to use the driver, though. > > I'll add a patch setting Kconfig BROKEN. Is it ok to do the reorg > after flagging it BROKEN? > > > > >> The pcm_lib.c changes may have broken other embedded drivers too. And > > > > I see no reason to suspect that embedded drivers will be any more or > > less affected than any other ALSA driver? > > The way I'm looking at the code, any CPU hardware that can't report > the position of a partially complete DMA transfer is probably broken. > Is the mpc5200 the only CPU that doesn't support this? Well, the following three are completely different things: A. the driver doesn't report the current DMA position B. the driver reports the wrong DMA position C. the driver calls snd_pcm_period_elapsed() at wrong timing AFAIK, the problem with mpc5200 is either B or C. It's not about A. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
