On 30/05/2014 04:13 πμ, Saran Neti wrote:
Hi Xenia,
Thanks for looking into this.
On Thu, May 29, 2014 at 6:31 PM, Xenia Ragiadakou <burzalodowa@xxxxxxxxx> wrote:
I misunderstood the following description regarding the slot id field of
Command Completion Event TRB:
"The Slot ID field shall be updated by the xHC to reflect the slot
associated with the
command that generated the event, with the following exceptions:
- The Slot ID shall be cleared to ‘0’ for No Op, Set Latency Tolerance
Value, Get Port
Bandwidth, and Force Event Commands.
- The Slot ID shall be set to the ID of the newly allocated Device Slot for
the Enable Slot
Command.
- The value of Slot ID shall be vendor defined when generated by a vendor
defined command.
This value is used as an index in the Device Context Base Address Array to
select the Device
Context of the source device. If this Event is due to a Host Controller
Command, then this field
shall be cleared to ‘0’."
The xhci spec rev1.0, for the Stop Endpoint Command, the Set TR Dequeue
Pointer Command and the Reset Endpoint Command, states explicitely that the
Command Completion Event placed on the Event Ring by the xHC shall have
initialized the Slot ID field to the value of the command’s Slot ID.
However, regarding the Reset Device Command it states that this field should
be cleared to zero. So, it was my mistake and your hardware is compatible
with the spec.
While the spec appears to be unambiguous about Slot ID for
Reset Device event TRB (always 0), in the case of
Set TR Dequeue Pointer Command, Section 4.6.10 says (in xHCI rev 1.1 -
is rev 1.0 similar?):
"To issue a Set TR Dequeue Pointer Command system software shall
perform the following operations:
...
Write the Host Controller Doorbell with DB Target = Host Controller Command
...
When a Set TR Dequeue Pointer Command is executed by the xHC it shall
perform the following operations:
...
Slot ID = The value of the command?s Slot ID.
..."
So, when xHC writes a Set TR Dequeue Pointer Command Completion Event
on the ring, there seem to be two different, possibly contradictory,
ways to do it:
1. Following 4.6.10, "Slot ID = The value of the command?s Slot ID."
2. Following your quoted block of text from 6.4.2.2, "If this Event is
due to a Host Controller Command, then this (Slot ID) field shall be
cleared to 0"
Both statements use 'shall', which according Word Usage is the new
'must'. Is there a Section-wise precedence order for cases like this?
The other two commands - Stop Endpoint Command and Reset Endpoint
Command are also subject to the same conundrum, if indeed there is
one.
If I'm mistaken, the email + patch I sent yesterday should be ignored:
http://www.spinics.net/lists/linux-usb/msg108566.html
Hi Saran,
I think the same ambiguation in spec holds also for the cases of Disable
Slot, Address Device, Configure Endpoint and Evaluate Context Command
Completion Event TRBs that they were using already the completion
event's Slot ID field, right? So, based on which criteria in some cases
completion event's slot id field can be used and in others cannot? I
don't know maybe Sarah or Mathias can clear that out.
regards,
Xenia
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
