From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Reyad Attiyat <reyad.attiyat@gmail.com>,
Mathias Nyman <mathias.nyman@intel.com>
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
Date: Tue, 30 Jun 2015 17:24:26 +0300 [thread overview]
Message-ID: <5592A69A.60105@linux.intel.com> (raw)
In-Reply-To: <CA+BWVURnoxdqG7JdRaXLuoipyCu5DCmkThxX68keFhdG8yYWiA@mail.gmail.com>
Hi
On 30.06.2015 04:54, Reyad Attiyat wrote:
> Hey Mathias,
>
> The intention is to send an extra endpoint packet of length zero as my
> wireless card needs this to function properly. I have skimmed through
> the xhci spec and assumed that each td would generate a packet. That
> is why I do not chain the last trb or add a interrupt flag, since I
> don't want to call the urb completion function called twice or called
> with the incorrect td or length.
I just found in xhci 1.0 spec section 4.9.1 that "To generate a zero-length
USB transaction software shall explicitly define a TD with a single transfer
TRB, and its TRB transfer length field shall equal 0"
So with this in mind your approach was correct, we shouldn't chain the last
data containing TRB with the zero TRB. This way xhci treats it as a separate TD.
Xhci controller thinks we have two TDs, while the driver only sees one TD.
This TD will interrupt in the middle, and has transferred all data before its last TRB.
I suspect that this may cause some issues, especially if we stop at the zero trb
and the driver has already returned the URB before the last TRB is handled.
If we continue with this option we need to make sure handle_tx_events(),
process_bulk_intr_td() and finish_td() work with with a SUCCESS bulk transfer
event in the middle of a TD. and that an transfer event for the zero transfer
received after URB is already returned doesn't mess anything up.
As the xhci specs in 4.9.1 requires us to define a TD with a single TRB for
the zero-packet, I think it would be better to add an additional TD to the bulk URB.
Then we should check if we need a zero transfer already in xchi_urb_enqueue(),
and make sure it allocates one more TD (doing size++ should be enough), and make sure
xhci_queue_bulk_tx() can handle bulk URBs with two TDs.
>
> I have since tried a patch that just chains the trbs together, with
> the zero-length trb, and this still creates a zero-length packet. I
> was thinking I could remove the use of the last_trb variable I was
> using and simply chain all the trbs together and place the interupt
> flag on the zero-length trb if it exsits. Also I noticed that the
> other host controller drivers (ehci and ohci) check to ensure that the
> endpoint is sending data out and that the urb length is greater than
> zero. I will add these checks as well to keep in line with the their
> implementation.
>
Adding the direction out check would be good.
> Do you think this is the best method for creating a zero-length
> packet, will every trb convert into at least one endpoint packet?
I think adding a new TD for the zero length transfer would be the best option.
This way we follow the specs. I started looking at zero-packet bulk issue
only after your first patch, so there might be many things I haven't taken into
consideration yet.
-Mathias
prev parent reply other threads:[~2015-06-30 14:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-29 0:53 [PATCH v2] usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers Reyad Attiyat
2015-06-29 15:48 ` Mathias Nyman
2015-06-30 1:54 ` Reyad Attiyat
2015-06-30 14:24 ` Mathias Nyman [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=5592A69A.60105@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=reyad.attiyat@gmail.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