Re: [PATCH v30 00/30] Introduce QC USB SND audio offloading support

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Dec 04, 2024 at 05:15:02PM -0800, Wesley Cheng wrote:
> 
> On 12/4/2024 1:14 PM, Cezary Rojewski wrote:
> > On 2024-12-03 5:57 PM, Greg KH wrote:
> >> On Tue, Dec 03, 2024 at 05:17:48PM +0100, Cezary Rojewski wrote:
> >>> On 2024-12-01 4:14 AM, Pierre-Louis Bossart wrote:
> >>>> Sorry to chime in late, I only look at email occasionally.
> >
> > ...
> >
> >>>>> I believe Amadeusz was still against having the two card design, and wants the routing to automatically happen when playback happens on the sound card created by the USB SND layer.  However, even with that kind of implementation, the major pieces brought in by this series should still be relevant, ie soc-usb and the vendor offload driver.  The only thing that would really change is adding a path from the USB SND PCM ops to interact with the ASoC entities.  Complexity-wise, this would obviously have a good amount of changes to the USB SND/ASoC core drivers.  Some things I can think of that we'd need to introduce:
> >>>>
> >>>> The notion of two cards was agreed inside Intel as far back as 2018, when Rakesh first looked at USB offload.
> >>>
> >>>
> >>> Well, I believe a lot has changed since then, not sure if USB Audio Offload
> >>> (UAOL) was even stable on the Windows solution back then. Obviously we want
> >>> to incorporate what we have learned during all that time into our solution
> >>> before it lands on upstream.
> >>
> >> Great, can you help review this series please?
> >
> > Hi Greg,
> >
> > This series is large and I'd suggest to split it up, what I touched on in my recent reply [1]. Please correct me if I'm wrong, but you mostly care about drivers/usb/* part. If so, the existing set could be split into USB-changes series, ALSA/ASoC-framework series and a third, holding bulk of QCOM-specific patches. Me and my team care mostly about the sound/* part and we don't hold much expertise in USB. I believe Mathias covers this part well though.
> >
> 
> I'm fine to split this into 3 different series if that helps with the reviews.  I was always under the impression that when we upstream things, we need to have an end to end use case within the same series, so that folks get the full picture.  I've gotten feedback where people were confused they couldn't find/follow the code flow, albeit those series were much much smaller.  If Greg is ok with it, I can split it up and have a link reference to the other series.

Yes, a full patch series is best as adding infrastructure in a
stand-alone series that no one uses isn't going to work well.

> I was able to reorganize the list a bit to what you recommended.  So the current layout is xHCI changes first, followed by the USB ALSA and ASoC changes, and lastly the QCOM/vendor specific modifications.

That sounds reasonable, hopefully it lets others review it easier.

thanks,

greg k-h