[alsa-devel] Driver code with mpc5200 pointer problem.

[Takashi Iwai]

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.


Takashi