Commit | Line | Data |
---|---|---|
e9bb6275 | 1 | ==================== |
81f6075e EP |
2 | Kernel driver ds2490 |
3 | ==================== | |
4 | ||
5 | Supported chips: | |
e9bb6275 | 6 | |
81f6075e EP |
7 | * Maxim DS2490 based |
8 | ||
9 | Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru> | |
10 | ||
11 | ||
12 | Description | |
13 | ----------- | |
14 | ||
2216886b | 15 | The Maxim/Dallas Semiconductor DS2490 is a chip |
81f6075e EP |
16 | which allows to build USB <-> W1 bridges. |
17 | ||
18 | DS9490(R) is a USB <-> W1 bus master device | |
19 | which has 0x81 family ID integrated chip and DS2490 | |
20 | low-level operational chip. | |
3823ee44 DF |
21 | |
22 | Notes and limitations. | |
e9bb6275 | 23 | |
3823ee44 DF |
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 minimum of 5.9mA and a | |
26 | maximum of 30.4 mA. (From DS2490.pdf) | |
3823ee44 DF |
27 | - The hardware will detect when devices are attached to the bus on the |
28 | next bus (reset?) operation, however only a message is printed as | |
29 | the core w1 code doesn't make use of the information. Connecting | |
30 | one device tends to give multiple new device notifications. | |
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 suggestion. It would take | |
33 | a write buffer and a read buffer (along with sizes) as arguments. | |
34 | The ds2490 block I/O command supports reset, write buffer, read | |
35 | buffer, and strong pullup all in one command, instead of the current | |
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 to have the match rom | |
38 | command and slave rom id prepended to the front of the requested | |
39 | write buffer, both of which are known to the driver. | |
40 | - The hardware supports normal, flexible, and overdrive bus | |
41 | communication speeds, but only the normal is supported. | |
42 | - The registered w1_bus_master functions don't define error | |
43 | conditions. If a bus search is in progress and the ds2490 is | |
44 | removed it can produce a good amount of error output before the bus | |
45 | search finishes. | |
46 | - The hardware supports detecting some error conditions, such as | |
47 | short, alarming presence on reset, and no presence on reset, but the | |
48 | driver doesn't query those values. | |
49 | - The ds2490 specification doesn't cover short bulk in reads in | |
50 | detail, but my observation is if fewer bytes are requested than are | |
51 | available, the bulk read will return an error and the hardware will | |
52 | clear the entire bulk in buffer. It would be possible to read the | |
53 | maximum buffer size to not run into this error condition, only extra | |
54 | bytes in the buffer is a logic error in the driver. The code should | |
b2702287 | 55 | match reads and writes as well as data sizes. Reads and |
3823ee44 DF |
56 | writes are serialized and the status verifies that the chip is idle |
57 | (and data is available) before the read is executed, so it should | |
58 | not happen. | |
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 the guest would operate | |
61 | normally the first time the module was loaded after qemu attached | |
62 | the ds2490 hardware, but if the module was unloaded, then reloaded | |
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 the bulk in would timeout | |
65 | even when the status shows data available. A bulk out write would | |
66 | show a successful completion, but the ds2490 status register would | |
67 | show 0 bytes written. Detaching qemu from the ds2490 hardware and | |
68 | reattaching would clear the problem. usbmon output in the guest and | |
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. | |
e9bb6275 MCC |
71 | |
72 | 03-06-2008 David Fries <David@Fries.net> |