Lines Matching refs:a
16 You should have received a copy of the GNU General Public License
27 This code implements a Ultra Wide Band stack for Linux, as well as
35 2. DWA: Device Wired Adaptor, a Wireless USB hub for wired
56 UWB is a wide-band communication protocol that is to serve also as the
61 UWB uses a band from roughly 3 to 10 GHz, transmitting at a max of
64 a bunch of ~1.5 GHz wide channels (or band groups) composed of three
67 driver considers them all a single one.
72 each superframe there is a Beacon Period (BP), where every device
73 transmit its beacon on a single MAS. The length of the BP depends on how
76 Devices have a MAC (fixed, 48 bit address) and a device (changeable, 16
78 info on what they are and do. They advertise their capabilities and a
92 The Wireless USB spec defines means to control a UWB radio and to
98 WUSB also defines a device called a Host Wire Adaptor (HWA), which in
99 mere terms is a USB dongle that enables your PC to have UWB and Wireless
100 USB. The Wireless USB Host Controller in a HWA looks to the host like a
108 Ultra-Wide-Band radio controller. The driver for this implements a
113 *HC*: the wireless USB host controller. It looks like a USB host
115 To the system it looks like a separate USB host. The driver (will)
116 implement a USB host controller (similar to UHCI, OHCI or EHCI)
117 for which the root hub is the radio...To reiterate: it is a USB
122 *WINET*: some HW provide a WiNET interface (IP over UWB). This
123 package provides a driver for it (it looks like a network
124 interface, winetX). The driver detects when there is a link up for
128 DWA: Device Wired Adaptor, a Wireless USB hub for wired devices
130 These are the complement to HWAs. They are a USB host for connecting
133 eye, it looks like a hub that connects upstream wirelessly.
135 We still offer no support for this; however, it should share a lot of
136 code with the HWA-RC driver; there is a bunch of factorization work that
144 to your host via a PCI interface. As in the case of the HWA, it has a
153 The main mission of the UWB stack is to keep a tally of which devices
162 each device that pops up in radio presence (ie: the UWB host receives a
163 beacon from it) you get a struct uwb_dev that will show up in
166 For each RC that is detected, a new struct uwb_rc and struct uwb_dev are
169 Each RC driver is implemented by a separate driver that plugs into the
170 interface that the UWB stack provides through a struct uwb_rc_ops. The
172 for HWA and WHCI RCs, so the driver is really a very thin transport that
180 Command execution is very simple: a command block is sent and a event
181 block or reply is expected back. For sending/receiving command/events, a
192 So let's say we connect a dongle to the system: it is detected and
195 Now we have a real HWA device connected and
202 [*] The stack should put a new RC to scan for devices
208 When a dongle is disconnected, /drivers/uwb/hwa-rc.c:hwarc_disconnect()/
214 So assuming we have devices and we have agreed for a channel to connect
227 daemon through a notification list.
229 UWBD wakes up and scans the event list; finds a beacon and adds it to
230 the BEACON CACHE (/uwb_beca/). If he receives a number of beacons from
231 the same device, he considers it to be 'onair' and creates a new device
245 The UWB stack maintains a local copy of DRP availability through
254 present in the current release. When completed they will enable a user
265 *WARNING* This section needs a lot of work!
278 HWA exposes a Host Controller interface (HWA-HC 0xe0/02/02). This has
282 We reserve UWB bandwidth for our Wireless USB Cluster, create a Cluster
289 that define a stream in the UWB channel time allocated for sending
291 Notifications (device initiated to host). Each host defines a
292 unique Wireless USB cluster through MMCs. Devices can connect to a
303 selects which one to connect to. Sends a /DN_Connect/ (device
309 the device. First we allocate a /fake port/ and assign an
312 sees a new connection, so he moves on to enable the fake port with a reset.
314 So now we are in the reset path -- we know we have a non-yet enumerated
317 exchange (FIXME: not yet done) and issue a /set address 0/ to bring the
327 Every time there is a successful transfer to/from a device, we update a
329 if the activity timestamp gets old, we ping the device by sending it a
330 Keep Alive IE; it responds with a /DN_Alive/ pong during the DNTS (this
331 arrives to us as a notification through
332 devconnect.c:wusb_handle_dn_alive(). If a device times out, we
340 If the device wants to disconnect, it will either die (ugly) or send a
341 /DN_Disconnect/ that will prompt a disconnection from the system.
346 /aimed/ at an endpoint in a WUSB device. This is the same for HWAs and
349 Each HC has a number of rpipes and buffers that can be assigned to them;
350 when doing a data transfer (xfer), first the rpipe has to be aimed and
354 Data buffers have to be segmented out before sending--so we send first a
355 header (segment request) and then if there is any data, a data buffer
362 be cleaned up a lot :)].
367 When the xfer is executed, we receive a notification that says data is
369 xfer.c:wa_handle_notif_xfer()). In there we read from the DTI endpoint a
371 (given when we issued it) and the segment number. If it was a data read,
383 The main xfer descriptor, wa_xfer (equivalent to a URB) contains an
385 information. Buried in there is a lot of URBs for executing the segments
400 rpipe to the endpoint where we have to transmit, create a transfer
405 a xfer abort request to the HC, cancel all the URBs we had submitted
417 *EVENT* -- Response to a command on the NEEP
429 Stuff related to the management of the first endpoint of a HWA USB