XHCI max scratchpad buffers seem to differ from specification

[Daniel Karling]

Hi,

I noticed that the macro for extracting the number of scratchpad
buffers to allocate from the HCSPARAMS2 register differs from what is
defined in the specification.

Current macro is in xhci.h:

/* bits 27:31 number of Scratchpad buffers SW must allocate for the HW */
#define HCS_MAX_SCRATCHPAD(p) (((p) >> 27) & 0x1f)

This macro is used in scratchpad_alloc and scratchpad_free in xhci-mem.c.

According to "eXtensible Host Controller Interface for Universal
Serial Bus (xHCI)" revision 1.1, section 5.3.4, bits 27:31 are only
the five low order bits and there are five high order bits to get from
bits 21:25.

Is there any particular reason for why the macro is as it is, or is this a bug?

Note: I haven't seen any host controllers actually requesting so many
scratchpad buffers that any of the high bits have to be used, but I
thought it might cause issues in the future.

Regards,
Daniel Karling
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Paul Zimmerman]

Sent: Wednesday, October 15, 2014 2:08 PM
Hi,
I noticed that the macro for extracting the number of scratchpad
buffers to allocate from the HCSPARAMS2 register differs from what is
defined in the specification.
/* bits 27:31 number of Scratchpad buffers SW must allocate for the HW */
#define HCS_MAX_SCRATCHPAD(p) (((p) >> 27) & 0x1f)
This macro is used in scratchpad_alloc and scratchpad_free in xhci-mem.c.
According to "eXtensible Host Controller Interface for Universal
Serial Bus (xHCI)" revision 1.1, section 5.3.4, bits 27:31 are only
the five low order bits and there are five high order bits to get from
bits 21:25.
Is there any particular reason for why the macro is as it is, or is this a bug?
Note: I haven't seen any host controllers actually requesting so many
scratchpad buffers that any of the high bits have to be used, but I
thought it might cause issues in the future.

That must be a relatively recent addition to the spec. In the original
v1.0 spec, only bits 31:27 are specified for this.

--
Paul

��칻�&�~�&���+-��ݶ��w��˛���m�b��n������ܨ}���Ơz�&j:+v����n�r��6;靫3��\
nnX��f�z��

[Daniel Karling]

Post by Paul Zimmerman
That must be a relatively recent addition to the spec. In the original
v1.0 spec, only bits 31:27 are specified for this.
--
Paul

That explains it, thanks. I could only find v1.1 when I noticed this.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html