From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: Streaming wake-up buffer from DSP to SoC over SPI Date: Tue, 16 Dec 2014 10:11:15 +0530 Message-ID: <20141216044115.GU16827@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by alsa0.perex.cz (Postfix) with ESMTP id AAF8626056A for ; Tue, 16 Dec 2014 05:41:15 +0100 (CET) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Dylan Reid Cc: Oder Chiou , Takashi Iwai , "alsa-devel@alsa-project.org" , Mark Brown List-Id: alsa-devel@alsa-project.org 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