1 ==================== 1 ====================
2 Kernel driver ds2490 2 Kernel driver ds2490
3 ==================== 3 ====================
4 4
5 Supported chips: 5 Supported chips:
6 6
7 * Maxim DS2490 based 7 * Maxim DS2490 based
8 8
9 Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru> 9 Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
10 10
11 11
12 Description 12 Description
13 ----------- 13 -----------
14 14
15 The Maxim/Dallas Semiconductor DS2490 is a chi 15 The Maxim/Dallas Semiconductor DS2490 is a chip
16 which allows to build USB <-> W1 bridges. 16 which allows to build USB <-> W1 bridges.
17 17
18 DS9490(R) is a USB <-> W1 bus master device 18 DS9490(R) is a USB <-> W1 bus master device
19 which has 0x81 family ID integrated chip and D 19 which has 0x81 family ID integrated chip and DS2490
20 low-level operational chip. 20 low-level operational chip.
21 21
22 Notes and limitations. 22 Notes and limitations.
23 23
24 - The weak pullup current is a minimum of 0.9m 24 - The weak pullup current is a minimum of 0.9mA and maximum of 6.0mA.
25 - The 5V strong pullup is supported with a min 25 - The 5V strong pullup is supported with a minimum of 5.9mA and a
26 maximum of 30.4 mA. (From DS2490.pdf) 26 maximum of 30.4 mA. (From DS2490.pdf)
27 - The hardware will detect when devices are at 27 - The hardware will detect when devices are attached to the bus on the
28 next bus (reset?) operation, however only a 28 next bus (reset?) operation, however only a message is printed as
29 the core w1 code doesn't make use of the inf 29 the core w1 code doesn't make use of the information. Connecting
30 one device tends to give multiple new device 30 one device tends to give multiple new device notifications.
31 - The number of USB bus transactions could be 31 - The number of USB bus transactions could be reduced if w1_reset_send
32 was added to the API. The name is just a su 32 was added to the API. The name is just a suggestion. It would take
33 a write buffer and a read buffer (along with 33 a write buffer and a read buffer (along with sizes) as arguments.
34 The ds2490 block I/O command supports reset, 34 The ds2490 block I/O command supports reset, write buffer, read
35 buffer, and strong pullup all in one command 35 buffer, and strong pullup all in one command, instead of the current
36 1 reset bus, 2 write the match rom command a 36 1 reset bus, 2 write the match rom command and slave rom id, 3 block
37 write and read data. The write buffer needs 37 write and read data. The write buffer needs to have the match rom
38 command and slave rom id prepended to the fr 38 command and slave rom id prepended to the front of the requested
39 write buffer, both of which are known to the 39 write buffer, both of which are known to the driver.
40 - The hardware supports normal, flexible, and 40 - The hardware supports normal, flexible, and overdrive bus
41 communication speeds, but only the normal is 41 communication speeds, but only the normal is supported.
42 - The registered w1_bus_master functions don't 42 - The registered w1_bus_master functions don't define error
43 conditions. If a bus search is in progress 43 conditions. If a bus search is in progress and the ds2490 is
44 removed it can produce a good amount of erro 44 removed it can produce a good amount of error output before the bus
45 search finishes. 45 search finishes.
46 - The hardware supports detecting some error c 46 - The hardware supports detecting some error conditions, such as
47 short, alarming presence on reset, and no pr 47 short, alarming presence on reset, and no presence on reset, but the
48 driver doesn't query those values. 48 driver doesn't query those values.
49 - The ds2490 specification doesn't cover short 49 - The ds2490 specification doesn't cover short bulk in reads in
50 detail, but my observation is if fewer bytes 50 detail, but my observation is if fewer bytes are requested than are
51 available, the bulk read will return an erro 51 available, the bulk read will return an error and the hardware will
52 clear the entire bulk in buffer. It would b 52 clear the entire bulk in buffer. It would be possible to read the
53 maximum buffer size to not run into this err 53 maximum buffer size to not run into this error condition, only extra
54 bytes in the buffer is a logic error in the 54 bytes in the buffer is a logic error in the driver. The code should
55 match reads and writes as well as data sizes !! 55 should match reads and writes as well as data sizes. Reads and
56 writes are serialized and the status verifie 56 writes are serialized and the status verifies that the chip is idle
57 (and data is available) before the read is e 57 (and data is available) before the read is executed, so it should
58 not happen. 58 not happen.
59 - Running x86_64 2.6.24 UHCI under qemu 0.9.0 59 - Running x86_64 2.6.24 UHCI under qemu 0.9.0 under x86_64 2.6.22-rc6
60 with a OHCI controller, ds2490 running in th 60 with a OHCI controller, ds2490 running in the guest would operate
61 normally the first time the module was loade 61 normally the first time the module was loaded after qemu attached
62 the ds2490 hardware, but if the module was u 62 the ds2490 hardware, but if the module was unloaded, then reloaded
63 most of the time one of the bulk out or in, 63 most of the time one of the bulk out or in, and usually the bulk in
64 would fail. qemu sets a 50ms timeout and th 64 would fail. qemu sets a 50ms timeout and the bulk in would timeout
65 even when the status shows data available. 65 even when the status shows data available. A bulk out write would
66 show a successful completion, but the ds2490 66 show a successful completion, but the ds2490 status register would
67 show 0 bytes written. Detaching qemu from t 67 show 0 bytes written. Detaching qemu from the ds2490 hardware and
68 reattaching would clear the problem. usbmon 68 reattaching would clear the problem. usbmon output in the guest and
69 host did not explain the problem. My guess 69 host did not explain the problem. My guess is a bug in either qemu
70 or the host OS and more likely the host OS. 70 or the host OS and more likely the host OS.
71 71
72 03-06-2008 David Fries <David@Fries.net> 72 03-06-2008 David Fries <David@Fries.net>
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.