From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Koul Subject: Re: [PATCH 1/2] ASoC: DPCM: make some DPCM API calls non static for compressed usage Date: Thu, 16 Jan 2014 20:29:04 +0530 Message-ID: <20140116145904.GI25466@intel.com> References: <1389804717-5985-1-git-send-email-liam.r.girdwood@linux.intel.com> <20140116123153.GP15567@sirena.org.uk> <20140116144042.GG25466@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by alsa0.perex.cz (Postfix) with ESMTP id 6AF312619F4 for ; Thu, 16 Jan 2014 17:01:50 +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: Takashi Iwai Cc: Liam Girdwood , alsa-devel@alsa-project.org, Mark Brown List-Id: alsa-devel@alsa-project.org On Thu, Jan 16, 2014 at 04:55:34PM +0100, Takashi Iwai wrote: > At Thu, 16 Jan 2014 20:10:42 +0530, > Vinod Koul wrote: > > > > On Thu, Jan 16, 2014 at 12:31:53PM +0000, Mark Brown wrote: > > > On Wed, Jan 15, 2014 at 04:51:56PM +0000, Liam Girdwood wrote: > > > > The ASoC compressed code needs to call the internal DPCM APIs in order to > > > > dynamically route compressed data to different DAIs. > > > > > > Applied, thanks. I'm holding off on the second patch for a little so > > > Vinod has a chance to say something since it's compressed stuff. > > Both look good to me, so > > > > Acked-by: Vinod Koul > > > > The second patch still needs an update for properly copying the hw_params. This > > was one of issue reported by qcom folks, but I don't want to hold these now. We > > can fix that as it will impact systems not have fixup function for BEs. > > One thing that makes me a bit nervous is that it's accessing the > actual PCM object. So far, sound/pcm.h is included there just because > it's re-using the same enum definitions, etc, but it doesn't mean that > it allows accessing a PCM object or function. > > If we bind a real PCM instance there, we should add the Kconfig > selection for SND_PCM from SND_COMPRESS_OFFLOAD. Makes sense, but is this a practical sceanrios. I dont think we have a sound card which supports offload only so SND_PCM will always be selected. This is also ASoC patch, so SND_SOC would be selected, which selects SND_PCM -- ~Vinod