[alsa-devel] Streaming wake-up buffer from DSP to SoC over SPI

[Vinod Koul]

On Mon, Dec 15, 2014 at 06:45:37PM -0800, Dylan Reid wrote:
> What is the right way to model a bursty, SPI based audio transfer?
> There could be hours between samples, then several seconds of audio
> will be ready.
> 
> The codec, an rt5677, is attached to the SoC with both an IIS bus and
> a SPI bus.  The IIS bus is used for normal audio playback and record.
> The SPI bus is used for transferring audio that caused a voice wake,
> "OK Google" in this case.
> 
> When the codec detects the wake up phrase, the SoC will read out two
> plus seconds of buffered data over the SPI bus and continue to stream
> audio data over SPI for the rest of the query.  Nexus 9 has a custom
> ioctl to access rt5677-spi and some user-space smarts to poll for more
> data.
why do we need custom ioctls :( current framework can address all your
needs..

> I was thinking of making a separate PCM device.  The odd things are
> that it would have to originate from soc/codecs, the codec would own
> the codec and cpu end of the link, and the hw_ptr position would need
> to be queried over SPI.  But it would make userspace access to it more
> standard looking.
okay here we have two things and they need to be decoupled. First is
detection by the codec for "OK Google". And second is getting the data (some
buffered while things are setup) to usermode.

For the former, the codec should implement a 'sink' for voice wake, so
essentially connecting the voice wake widget to MIC pins will power up codec
and codec can do the detection while rest of the system is sleeping

Once the event is detected, codec should send an interrupt to host, thereby
waking up the system. The driver will figure out that it is voice wake event
and should set the alsa kcontrol status, on which usermode needs to listen.

Now usermode knows the event occurred so lets read the data. During all the
activation, wakeup etc some data would be buffered, in you case 2 secs. IMO
PCM devices aren't suited for this, so you need to use a compressed device.
The data can come from SPI port (we can get all the buffered data in one big
burst". I know one vendor has implemented such a mechanism.

The device here wont be any different than regular PCM/Compressed devices.
Assume the data path is SPI rather than I2S so things would be modelled that
way. You still need to setup SPI port, DMAs like you would do on I2S.

HTH
-- 
~Vinod