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