[alsa-devel] [PATCH v4 07/15] ALSA: usb-audio: correct ep use_count semantics (add set_param flag)

[Takashi Iwai]

At Mon, 7 Oct 2013 21:31:35 +0200 (CEST),
Eldad Zack wrote:
> 
> 
> 
> On Mon, 7 Oct 2013, Takashi Iwai wrote:
> 
> > At Sun,  6 Oct 2013 22:31:12 +0200,
> > Eldad Zack wrote:
> > > 
> > > Currently, use_count is used in snd_usb_endpoint_set_params to
> > > ensure the parameters don't get changed for an in-use endpoint.
> > > 
> > > However, there is a subtle condition where this check fails -
> > > if hw_params is called on both substreams before calling prepare (for
> > > playback) or start trigger (for capture): the endpoint is not yet
> > > started, i.e., snd_usb_endpoint_start() does not yet increment use_count.
> > > 
> > > This adds a flag to check if the parameters are set, but does not
> > > omit checking the use_count.
> > > 
> > > Signed-off-by: Eldad Zack <eldad at fogrefinery.com>
> > > 
> > > ---
> > > v2: Cleaned up the patch, now it does only one thing (add the flag
> > > and the check).
> > 
> > I guess this logic doesn't work if a capture stream is re-prepared
> > before started.  I know that you'll change the capture stream starting
> > in the later patch, but then this patch must be applied after that,
> > because it implicitly assumes the scheme.
> 
> Yes and it causes a regression too, it prevents full-duplex usage
> (with jack or client that use the same sequence). Sorry, I forgot to add 
> that to the commit message.
> 
> I left this so the change is clear, I figured it helps when reading the 
> history.
> Should I combine this with the later patch? Or should I put a notice in
> this commit message that "this patch breaks... will be fixed later 
> by..."?

At best shuffle the order of patches so that this one is applied after
the required patches.

> BTW - sorry if that's a trivial question - is it possible for ops to 
> race, or do the ops get serialized?
> If it is possible, I believe there's a few places that need locking.

Which ops specifically?  For a PCM substream, it's serialized.  For
duplex substreams, both can be called at the same time, thus you'd
need to protect concurrent accesses, if any.


Takashi