Handle SET_ADDRESS directly when each controller receives SETUP, before
passing other requests to the core. Cancel transfers, send the status
response in the driver and queue usb_core_notify_set_address(); the core
only updates its address/configuration state. Remove usb_drv_set_address
and avoid a request callback from the core back into the controller.
Keep status completions for this driver-owned request out of the core EP0
state machine. ARC writes DEVICEADDR and notifies after successful status
IN completion; other controllers retain their existing register/status
ordering or automatic address handling. Use IRQ-local operations on
DesignWare rather than helpers which unconditionally re-enable its IRQ.
Take the low seven bits of wValue; do not impose new validation on the
unspecified wIndex/wLength fields. Convert all eleven firmware backends;
the separate hwstub API is unchanged.
Change-Id: I7b96275df90c14ef4a9954f04ac6fdc004ec8d6c
this commit is a combination of the following changes, which
significantly refactors usb core and class drivers.
1. unify usb buffers of each class driver to reduce iram usage
currently, many class drivers allocate their own buffer to receive
control out data, which is a waste of iram.
share one common buffer for that usage to address the issue.
2. simplify control request handling by implicitly receiving write
request data packets
change 1 above fixed the data destination. therefore, having the core
receive the data allows us to reduce the class driver's work and
simplifies the api.
3. enhance usb core's control request handling and unify the legacy
driver api
in order to implement change 2, both the legacy and new driver apis
should be supported. so that, using the designware driver as a
reference, the new driver api functionality is move into usb core.
this simplifies the usb device drivers by requiring them to implement
only the functionalities equivalent to the legacy api.
tested with ipodvideo(arc) and erosqnative(designware)
Change-Id: I3627daa90278751f599e2108ec150ec3f8f6c524
the capabilities of endpoint of several devices such as dwc2 change during
runtime, so they cannot be determined during driver initialization.
therefore, allocation using ep_specs is inappropriate.
to support these devices, add functions to the driver that determine whether
endpoints are available and make allocation more flexible.
tested with ipodvideo(arc) and erosqnative(designware)
Change-Id: I8005c17f3d763cd17306bf49918e1cd8084bdeff
this commit has following changes:
- introduce `usb_drv_ep_spec` table to udc drivers, which represents
endpoint characteristics.
- introduce 'ep_allocs' table to class drivers, which represents what
endpoint type does the class driver want.
- implement endpoint matching logic to usb core.
this is a required step to implement usb config switching, because we
need to create config descriptors without actually initializing endpoints.
Change-Id: I11c324cd35189ab636744488f6259d0cdb2179f0
IMHO the current name is somewhat misleading:
- usb_drv_send() is blocking and we have usb_drv_send_nonblocking()
for the non-blocking case. This inconsistent naming can only
promote confusion. (And what would we call a blocking receive?)
- Other hardware abstraction APIs in Rockbox are usually blocking:
storage, LCD, backlight, audio... in other words, blocking is the
default expected behavior, with non-blocking calls being a rarity.
Change-Id: I05b41088d09eab582697674f4f06fdca0c8950af
Loop terminator needed a preincrement rather than postincrement, and
also used a proper #define instead of a magic number.
Change-Id: Iafd6a0dce0304cb94e4f1d04cce46d2ca603507a
