73 lines · plain
1====================2Kernel driver ds24903====================4 5Supported chips:6 7 * Maxim DS2490 based8 9Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>10 11 12Description13-----------14 15The Maxim/Dallas Semiconductor DS2490 is a chip16which allows to build USB <-> W1 bridges.17 18DS9490(R) is a USB <-> W1 bus master device19which has 0x81 family ID integrated chip and DS249020low-level operational chip.21 22Notes and limitations.23 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 a26 maximum of 30.4 mA. (From DS2490.pdf)27- The hardware will detect when devices are attached to the bus on the28 next bus (reset?) operation, however only a message is printed as29 the core w1 code doesn't make use of the information. Connecting30 one device tends to give multiple new device notifications.31- The number of USB bus transactions could be reduced if w1_reset_send32 was added to the API. The name is just a suggestion. It would take33 a write buffer and a read buffer (along with sizes) as arguments.34 The ds2490 block I/O command supports reset, write buffer, read35 buffer, and strong pullup all in one command, instead of the current36 1 reset bus, 2 write the match rom command and slave rom id, 3 block37 write and read data. The write buffer needs to have the match rom38 command and slave rom id prepended to the front of the requested39 write buffer, both of which are known to the driver.40- The hardware supports normal, flexible, and overdrive bus41 communication speeds, but only the normal is supported.42- The registered w1_bus_master functions don't define error43 conditions. If a bus search is in progress and the ds2490 is44 removed it can produce a good amount of error output before the bus45 search finishes.46- The hardware supports detecting some error conditions, such as47 short, alarming presence on reset, and no presence on reset, but the48 driver doesn't query those values.49- The ds2490 specification doesn't cover short bulk in reads in50 detail, but my observation is if fewer bytes are requested than are51 available, the bulk read will return an error and the hardware will52 clear the entire bulk in buffer. It would be possible to read the53 maximum buffer size to not run into this error condition, only extra54 bytes in the buffer is a logic error in the driver. The code should55 match reads and writes as well as data sizes. Reads and56 writes are serialized and the status verifies that the chip is idle57 (and data is available) before the read is executed, so it should58 not happen.59- Running x86_64 2.6.24 UHCI under qemu 0.9.0 under x86_64 2.6.22-rc660 with a OHCI controller, ds2490 running in the guest would operate61 normally the first time the module was loaded after qemu attached62 the ds2490 hardware, but if the module was unloaded, then reloaded63 most of the time one of the bulk out or in, and usually the bulk in64 would fail. qemu sets a 50ms timeout and the bulk in would timeout65 even when the status shows data available. A bulk out write would66 show a successful completion, but the ds2490 status register would67 show 0 bytes written. Detaching qemu from the ds2490 hardware and68 reattaching would clear the problem. usbmon output in the guest and69 host did not explain the problem. My guess is a bug in either qemu70 or the host OS and more likely the host OS.71 7203-06-2008 David Fries <David@Fries.net>73