Hi Mark,
On Saturday 20 August 2011 09:01:14 Mark Brown wrote:
So, the issue here is that the CODEC you're using on your system lacks DAC mute support and doesn't handle the end of the input stream gracefully? This doesn't sound like a McPDM specific issue at all, and I'm slightly surprised we don't run into it more often.
Currently the sequence we use on stream teardown is:
- Mute.
- Stop stream.
- Wait for the DAPM teardown time.
- Power down.
but it seems like what your CODEC actually wants is:
- Power down.
- Stop stream.
Something like that, yes.
which isn't at all unresonable and if the CODEC is actually able to support that mode of operation well then it'll be lower power. This seems like something we should be supporting in the core as I would expect other devices will find it useful, PDM class D speaker drivers being the most obvious example.
That's good, if we have other users with similar requirements towards the sequencing. One thing, which might need special care in the down sequence:
1. Stop platform (DMA) 2. Power down (mostly codec side) 3. Stop cpu dai
I'm not sure about this, but we should not have running DMA after trigger:stop?
I do think it'd be helpful to split this code out as a separate patch as it's the controversial bit...
It is not that easy. There's no incremental way from the old driver to the new one. What I can try however is to write an intermediate driver, which does not have the delayed sequencing. I know that this is a bit problematic, and it is not going to work as good as the driver in this series, but probably it will give the needed separation of the sequencing part. This going to take some time, since I need to - kind of - write a new driver, which is in half way between the two versions ;)
-- Péter