From: Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH] ALSA SOC driver for s3c24xx: 8 bit sound
	fix
Date: Mon, 10 Nov 2008 08:30:19 +0100
Message-ID: <s5h3ai0jawk.wl%tiwai@suse.de>
References: <12261302562876-git-send-email-chripell@gmail.com>
	<s5h63mwjcr9.wl%tiwai@suse.de>
	<cabda6420811092320m41cecd4brd7e20c1ce338957e@mail.gmail.com>
Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from mx1.suse.de (ns.suse.de [195.135.220.2])
	by alsa0.perex.cz (Postfix) with ESMTP id 03CC224385
	for <alsa-devel@alsa-project.org>; Mon, 10 Nov 2008 08:30:20 +0100 (CET)
In-Reply-To: <cabda6420811092320m41cecd4brd7e20c1ce338957e@mail.gmail.com>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
	<mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Sender: alsa-devel-bounces@alsa-project.org
Errors-To: alsa-devel-bounces@alsa-project.org
To: chri <chripell@gmail.com>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@opensource.wolfsonmicro.com>, linux-arm-kernel@lists.arm.linux.org.uk, ben-linux@fluff.org
List-Id: alsa-devel@alsa-project.org

At Mon, 10 Nov 2008 08:20:13 +0100,
chri wrote:
> 
> Hi,
> 
> On Mon, Nov 10, 2008 at 7:50 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Sat,  8 Nov 2008 08:44:16 +0100,
> >
> > I don't think it's good to overwrite the global variables in this way.
> >
> 
> I see. I just tried to keep the modifications minimal. Perhaps Ben
> Dooks, the author of the code, can suggest a better way to proceed. I
> will be happy to follow his suggestion.

OK.

> > And, what if playback and capture use the different formats in full
> > duplex streams...?
> >
> 
> I dont' think that this is possible on the S3C24{1,4}0 since the
> configuration registers are shared between playback and record path
> (so this applies to sample frequency too for example). I guess you are
> suggesting that given parameters should be checked against those of
> the currently playing stream to see if they are compatible?

Yes.  Without a proper check and/or hw_param constraints, the driver
thinks the streams are individual and allows apps to set up
independent parameters, which may result in a hardware error.

Creating hw constraints sharing both playback and capture streams is a
bit tricky and even racy.  But, it'd be much better than nothing.


thanks,

Takashi