mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: William Wu <william.wu@rock-chips.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"frank.wang@rock-chips.com" <frank.wang@rock-chips.com>,
	"jianwei.zheng@rock-chips.com" <jianwei.zheng@rock-chips.com>,
	"yangbin@rock-chips.com" <yangbin@rock-chips.com>
Subject: Re: [PATCH] usb: dwc3: gadget: Properly handle miss isoc event
Date: Thu, 13 Jul 2023 15:45:44 +0000	[thread overview]
Message-ID: <20230713154535.hsizn2e2fqenkslb@synopsys.com> (raw)
In-Reply-To: <20230713025149.24276-1-william.wu@rock-chips.com>

On Thu, Jul 13, 2023, William Wu wrote:
> If miss isoc event happens, the current code just set
> the req status to -EXDEV and giveback the req to the usb
> gadget driver, and then stop the active transfer with the
> cmd DWC3_DEPCMD_ENDTRANSFER and wait for a XferNotReady
> event to restart a transfer again. However, for isoc
> ep in transfer, it cause to lost the isoc data of the
> req.

That's intentional and expected behavior.

> 
> This patch moves the miss isoc req to pending_list in
> order to restart transfer immediately instead of give
> back the req to the usb gadget driver.

No. Now you're breaking the usage of isoc endpoint and also re-ordering
the transfer sequence.

> 
> Signed-off-by: William Wu <william.wu@rock-chips.com>

Regardless of direction, isoc data is time sensitive. If an isoc request
(or part of it) does not go out at a scheduled interval, then it's
dropped.

You should look into why it's being dropped (whether it's due to
software or hardware latency) and see if you can help it.

If your application does not care about the timing, then perhaps it
should use a different endpoint type.

If your application protocol requires the use of isoc endpoint and
somehow also demands no data drop tolerance, then you can workaround
that from the gadget driver. However I doubt this is the case.

BR,
Thinh

      reply	other threads:[~2023-07-14  0:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13  2:51 William Wu
2023-07-13 15:45 ` Thinh Nguyen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230713154535.hsizn2e2fqenkslb@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=frank.wang@rock-chips.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jianwei.zheng@rock-chips.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=william.wu@rock-chips.com \
    --cc=yangbin@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®