From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Vorontsov Subject: Re: [PATCH] ALSA: soc - fsl_ssi.c fix audio capture Date: Fri, 4 Jul 2008 19:43:13 +0400 Message-ID: <20080704154313.GA11635@polina.dev.rtsoft.ru> References: <20080703143714.GA7003@polina.dev.rtsoft.ru> <20080703144254.GB652@sirena.org.uk> Reply-To: avorontsov@ru.mvista.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from buildserver.ru.mvista.com (unknown [85.21.88.6]) by alsa0.perex.cz (Postfix) with ESMTP id 3D0F024A83 for ; Fri, 4 Jul 2008 17:43:15 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Timur Tabi Cc: Takashi Iwai , alsa-devel@alsa-project.org, Mark Brown List-Id: alsa-devel@alsa-project.org On Fri, Jul 04, 2008 at 07:02:17AM -0400, Timur Tabi wrote: > > On Jul 3, 2008, at 10:42 AM, Mark Brown wrote: > >> On Thu, Jul 03, 2008 at 06:37:14PM +0400, Anton Vorontsov wrote: >>> Since we're using SSI in synchronous mode, the STCCR register >>> controls >>> both the receive and transmit sections. So, when we're trying to >>> record >>> anything, stccr register does not get initialized, thus the output >>> file >>> filled with the white noise. >> >>> Fix this by initializing the STCCR for both playback and capture. If >>> TX/RX widths don't match, return that we're busy at the moment. >> >>> Signed-off-by: Anton Vorontsov >> >> Acked-by: Mark Brown >> >> but Timur needs to ack it since I don't have any particular knowledge >> of >> the hardware. > > Anton has the right idea, but I'm not sure the fix is the best. I was > planning on posting my fix after I got back from vacation. > > Part of the problem is that STCK and SRCK can be wired together, which > means that even though you're not in synchronous mode, the sample rates > have to match. For the 8610 HPCD, this isn't a problem, but the SSI > driver is supposed to support more than just that board. We need device > tree additions to cover all cases. Ok, we can set both. > Anton, are you sure returning -EBUSY is the right fix? Since we're using prepare(), yes. But we probably should use hw_params() and return -EINVAL. > Would this make > applications like mplayer detect the problem and automatically pick a > matching sample format that does work? I don't think that anyone tries to negotiate if/when prepare() failed. But if hw_params() failed, then yes. Here is updated patch. Also new patch for the codec used on the HPCD: it seem has the similar issue, but wrt sampling rate. On Fri, Jul 04, 2008 at 04:49:29PM +0200, Takashi Iwai wrote: > I guess it won't work in such a way. But, at least, you can avoid > unexpected machine state, which resulted in white noise. > Since you will post another patch (I suppose it's with hw_constraint > coupling), I'll postpone this patch as now. Hm... Not sure hw_constraints are appropriate in these cases, as see it, they all called in the open routines, while we set up things much later -- in the hw_params, so we want "dynamic" constraints (please take a look at the second patch, it is simpler). Thanks, -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2