Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 26 Jul 2023 14:31:58 +0200
Message-ID: <87msziyhtt.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Wesley Cheng <quic_wcheng@quicinc.com>
Cc:     <agross@kernel.org>, <andersson@kernel.org>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <catalin.marinas@arm.com>, <will@kernel.org>,
        <mathias.nyman@intel.com>, <gregkh@linuxfoundation.org>,
        <lgirdwood@gmail.com>, <broonie@kernel.org>, <perex@perex.cz>,
        <tiwai@suse.com>, <srinivas.kandagatla@linaro.org>,
        <bgoswami@quicinc.com>, <Thinh.Nguyen@synopsys.com>,
        <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-usb@vger.kernel.org>, <alsa-devel@alsa-project.org>,
        <quic_jackp@quicinc.com>, <pierre-louis.bossart@linux.intel.com>,
        <oneukum@suse.com>, <albertccwang@google.com>,
        <o-takashi@sakamocchi.jp>
Subject: Re: [PATCH v4 18/32] sound: usb: Introduce QC USB SND offloading support
In-Reply-To: <243ee81d-d46d-e05a-1fcd-35e6301a39cd@quicinc.com>
References: <20230725023416.11205-1-quic_wcheng@quicinc.com>
        <20230725023416.11205-19-quic_wcheng@quicinc.com>
        <87bkg0v4ce.wl-tiwai@suse.de>
        <243ee81d-d46d-e05a-1fcd-35e6301a39cd@quicinc.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Wed, 26 Jul 2023 00:59:57 +0200,
Wesley Cheng wrote:
> 
> >> +static int enable_audio_stream(struct snd_usb_substream *subs,
> >> +				snd_pcm_format_t pcm_format,
> >> +				unsigned int channels, unsigned int cur_rate,
> >> +				int datainterval)
> >> +{
> > 
> > ... this implementation, I wonder whether it'd be better to modify and
> > export  snd_usb_hw_params() snd snd_usb_hw_free() to fit with qcom
> > driver.  Then you can avoid lots of open code.
> > 
> 
> I think the problem is that snd_usb_hw_params assumes that we've
> already done a PCM open on the PCM device created by USB SND.
> However, with the offload path, we don't reference the USB PCM device,
> but the one created by the platform sound card.  Hence, I don't have
> access to the snd_pcm_substream.
> 
> I attempted to derive snd_pcm_substream from snd_usb_substream, but
> since PCM open isn't run, it doesn't provide a valid structure.
> 
> What do you think about adding a wrapper to snd_usb_hw_params?  Have a
> version that will take in snd_usb_substream, and another that is
> registered to hw_params().

Yes, that's what I had in mind, too.

> > In general, if you see a direct use of chip->mutex, it can be often
> > done better in a different form.  The use of an internal lock or such
> > from an external driver is always fragile and error-prone.
> > 
> > Also, the current open-code misses the potential race against the
> > disconnection during the operation.  In snd-usb-audio, it protects
> > with snd_usb_lock_shutdown() and snd_usb_unlock_shutdown() pairs.
> > 
> 
> I agree...I think then the best approach would be something like the
> above, ie:
> 
> int snd_usb_hw_params(struct snd_pcm_substream *substream,
> 			     struct snd_pcm_hw_params *hw_params)
> {
> 	struct snd_usb_substream *subs = substream->runtime->private_data;
> 
> 	snd_usb_ep_attach(subs, hw_params);
> ...
> 
> int snd_usb_ep_attach(...)
> {
> 	//implementation of current code in snd_usb_hw_params()
> }
> EXPORT_SYMBOL(snd_usb_ep_attach);

Yes, exactly something like that ;)


thanks,

Takashi