Re: [PATCH] usb: gadget: u_audio.c: Adding Playback Pitch ctl for sync playback

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Oct 06, 2021 at 08:43:08AM +0200, Pavel Hofman wrote:
> 
> Dne 05. 10. 21 v 13:31 Greg KH napsal(a):
> > On Sat, Sep 25, 2021 at 04:30:03PM +0200, Pavel Hofman wrote:
> > > EP IN is hard-coded as ASYNC both in f_uac1 and f_uac2 but u_audio sends
> > > steady number of audio frames in each USB packet, without any control.
> > > 
> > > This patch adds 'Playback Pitch 1000000' ctl analogous to the existing
> > > 'Capture Pitch 1000000' ctl. The calculation of playback req->length in
> > > u_audio_iso_complete respects the Playback Pitch ctl value to 1ppm now.
> > > 
> > > Max. value for Playback Pitch is configured by the existing parameter
> > > uac2_opts->fb_max, used also for the Capture Pitch.
> > > 
> > > Since the EP IN packet size can be increased by uac2_opts->fb_max now,
> > > maxPacketSize for the playback direction is calculated by the same
> > > algorithm as for the async capture direction in
> > > f_uac2.c:set_ep_max_packet_size.
> > > 
> > > Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
> > > ---
> > >   drivers/usb/gadget/function/f_uac2.c  |  5 +-
> > >   drivers/usb/gadget/function/u_audio.c | 93 ++++++++++++++++++++-------
> > >   2 files changed, 74 insertions(+), 24 deletions(-)
> > 
> > Does not apply to my tree, what kernel release / branch did you make
> > this against?
> > 
> 
> Greg, the patch requires patch 0560c9c ("usb: gadget: f_uac2: fixed EP-IN
> wMaxPacketSize") which I sent prior to this one (not as a patch series, this
> patch was not ready at that time). You applied 0560c9c to your usb-linus
> yesterday, hence this patch applies cleanly to usb-linus now.
> 
> Your branch usb-next does not have 0560c9c yet, therefore the patch fails.
> But both patches apply cleanly to usb-next as a series, tested just now.
> 
> This patch ("usb: gadget: u_audio.c: Adding Playback Pitch ctl for sync
> playback") is not a bugfix and can wait in usb-next.
> 
> That goes back to my question of what are the rules for the two of your
> branches. What if a new patch requires patches from both usb-linus (bugfix)
> and usb-next (new features)?

I have 2 branches (well 3) in my tree:
	master - tracks Linus's tree
	usb-linus - patches to go to Linus for "this" release
	usb-next - patches to go to Linus for the "next" release


So bugfixes go into usb-linus, and new features go into usb-next.

After the patches in usb-linus get merged into Linus, I merge that
branch (well Linus's -rc release) into the usb-next branch so that
dependencies can get resolved and bugfixes show up for testing.

If you have patches like this that rely on one, I need to know that
otherwise problems can happen, as you can see here.  Please just resend
this after it hits usb-next, or tell me and I will wait until that
happens myself.

does this help?

thanks,

greg k-h