[alsa-devel] Driver code with mpc5200 pointer problem.
tiwai at suse.de
Mon Apr 27 16:47:37 CEST 2009
At Mon, 27 Apr 2009 10:42:10 -0400,
Jon Smirl wrote:
> On Mon, Apr 27, 2009 at 10:24 AM, Mark Brown <broonie at sirena.org.uk> 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 at sirena.org.uk> 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.
More information about the Alsa-devel