Re: [PATCH v6 18/22] usb: dwc2: host: Schedule periodic right away if it's time

[Kever Yang]

Doug,

On 02/01/2016 06:09 AM, Doug Anderson wrote:
> Kever,
>
> On Sun, Jan 31, 2016 at 1:36 AM, Kever Yang <kever.yang@xxxxxxxxxxxxxx> wrote:
> > Doug,
> >
> >
> > On 01/29/2016 10:20 AM, Douglas Anderson wrote:
> > > In dwc2_hcd_qh_deactivate() we will put some things on the
> > > periodic_sched_ready list.  These things won't be taken off the ready
> > > list until the next SOF, which might be a little late.  Let's put them
> > > on right away.
> > >
> > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> > > Tested-by: Heiko Stuebner <heiko@xxxxxxxxx>
> > > Tested-by: Stefan Wahren <stefan.wahren@xxxxxxxx>
> > > ---
> > > Changes in v6:
> > > - Add Heiko's Tested-by.
> > > - Add Stefan's Tested-by.
> > >
> > > Changes in v5: None
> > > Changes in v4:
> > > - Schedule periodic right away if it's time new for v4.
> > >
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > >    drivers/usb/dwc2/hcd_queue.c | 18 ++++++++++++++++--
> > >    1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
> > > index 9b3c435339ee..3abb34a5fc5b 100644
> > > --- a/drivers/usb/dwc2/hcd_queue.c
> > > +++ b/drivers/usb/dwc2/hcd_queue.c
> > > @@ -1080,12 +1080,26 @@ void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
> > > *hsotg, struct dwc2_qh *qh,
> > >           * Note: we purposely use the frame_number from the "hsotg"
> > > structure
> > >           * since we know SOF interrupt will handle future frames.
> > >           */
> > > -       if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
> > > +       if (dwc2_frame_num_le(qh->next_active_frame, hsotg->frame_number))
> > > {
> > > +               enum dwc2_transaction_type tr_type;
> > > +
> > > +               /*
> > > +                * We're bypassing the SOF handler which is normally what
> > > puts
> > > +                * us on the ready list because we're in a hurry and need
> > > to
> > > +                * try to catch up.
> > > +                */
> > > +               dwc2_sch_vdbg(hsotg, "QH=%p IMM ready fn=%04x,
> > > nxt=%04x\n",
> > > +                             qh, frame_number, qh->next_active_frame);
> > >                  list_move_tail(&qh->qh_list_entry,
> > >                                 &hsotg->periodic_sched_ready);
> > > -       else
> > > +
> > > +               tr_type = dwc2_hcd_select_transactions(hsotg);
> > Do we need to add select_transactions call here? If we get into this
> > function in interrupt
> > and once we put the qh in ready queue, the qh can be handled in this frame
> > again by the
> > later function call of dwc_hcd_select_transactions, so what we need to to
> > here is put
> > it in ready list instead of inactive queue, and wait for the schedule.
> I'm not sure I understand.  Can you restate?
>
>
> I'll try to explain more in the meantime...
>
> Both before and after my change, this function would place something
> on the ready queue if the next_active_frame <= the frame number as of
> last SOF interrupt (aka hsotg->frame_number).  Otherwise it goes on
> the inactive queue.  Assuming that the previous change ("usb: dwc2:
> host: Manage frame nums better in scheduler") worked properly then
> next_active_frame shouldn't be less than (hsotg->frame_number - 1).
> Remember that next_active_frame is always 1 before the wire frame, so
> if "next_active_frame == hsotg->frame_number - 1" it means that we
> need to get the transfer on the wire _right away_.  If
> "next_active_frame == hsotg->frame_number" the transfer doesn't need
> to go on the wire right away, but since dwc2 can be prepped one frame
> in advance it doesn't hurt to give it to the hardware right away if
> there's space.
>
> As I understand it, if we stick something on the ready queue it won't
> generally get looked at until the next SOF interrupt.  That means
> we'll be too late if "next_active_frame == hsotg->frame_number - 1"
> and we'll possibly be too late (depending on interrupt latency) if
> "next_active_frame == hsotg->frame_number"
I understand this patch and agree with your point of schedule the
periodic right away instead of at least next frame.
My point is, there are only two call to dwc2_hcd_qh_deactivate(), from
dwc2_hcd_urb_dequeue() and dwc2_release_channel(), we don't need
to do the schedule for dequeue, and there is one
dwc2_hcd_select_transactions() call at the end of dwc2_release_channel(),
maybe we don't need another dwc2_hcd_select_transactions() here.

I think the duration from this point to the function call of 
dwc2_hcd_select_transactions()
in dwc2_release_channel() will be the main factor for us to decide if
we need to add a function call of  dwc2_hcd_select_transactions() here.

Thanks,
- Kever
> Note that before my series, there were more places than just the SOF
> interrupt that would update hsotg->frame_number (see "usb: dwc2: host:
> Manage frame nums better in scheduler" for fix).  Also before my
> series (specially "usb: dwc2: host: Manage frame nums better in
> scheduler") we used the actual current frame number when doing
> comparisons.  Also before my series (specifically "usb: dwc2: host:
> Properly set even/odd frame") we didn't really place things in the
> frame that they were scheduled in anyway.
>
>
> Also note that I believe that when dwc2_hcd_qh_deactivate() is called
> our spinlock is held which means that the SOF interrupt either ran
> before our function or won't run till after it.
>
> > > +               if (tr_type != DWC2_TRANSACTION_NONE)
> > > +                       dwc2_hcd_queue_transactions(hsotg, tr_type);
> > > +       } else {
> > >                  list_move_tail(&qh->qh_list_entry,
> > >                                 &hsotg->periodic_sched_inactive);
> > > +       }
> > >    }
> > >      /**