0001 ====================
0002 Kernel driver ds2490
0003 ====================
0004
0005 Supported chips:
0006
0007 * Maxim DS2490 based
0008
0009 Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
0010
0011
0012 Description
0013 -----------
0014
0015 The Maxim/Dallas Semiconductor DS2490 is a chip
0016 which allows to build USB <-> W1 bridges.
0017
0018 DS9490(R) is a USB <-> W1 bus master device
0019 which has 0x81 family ID integrated chip and DS2490
0020 low-level operational chip.
0021
0022 Notes and limitations.
0023
0024 - The weak pullup current is a minimum of 0.9mA and maximum of 6.0mA.
0025 - The 5V strong pullup is supported with a minimum of 5.9mA and a
0026 maximum of 30.4 mA. (From DS2490.pdf)
0027 - The hardware will detect when devices are attached to the bus on the
0028 next bus (reset?) operation, however only a message is printed as
0029 the core w1 code doesn't make use of the information. Connecting
0030 one device tends to give multiple new device notifications.
0031 - The number of USB bus transactions could be reduced if w1_reset_send
0032 was added to the API. The name is just a suggestion. It would take
0033 a write buffer and a read buffer (along with sizes) as arguments.
0034 The ds2490 block I/O command supports reset, write buffer, read
0035 buffer, and strong pullup all in one command, instead of the current
0036 1 reset bus, 2 write the match rom command and slave rom id, 3 block
0037 write and read data. The write buffer needs to have the match rom
0038 command and slave rom id prepended to the front of the requested
0039 write buffer, both of which are known to the driver.
0040 - The hardware supports normal, flexible, and overdrive bus
0041 communication speeds, but only the normal is supported.
0042 - The registered w1_bus_master functions don't define error
0043 conditions. If a bus search is in progress and the ds2490 is
0044 removed it can produce a good amount of error output before the bus
0045 search finishes.
0046 - The hardware supports detecting some error conditions, such as
0047 short, alarming presence on reset, and no presence on reset, but the
0048 driver doesn't query those values.
0049 - The ds2490 specification doesn't cover short bulk in reads in
0050 detail, but my observation is if fewer bytes are requested than are
0051 available, the bulk read will return an error and the hardware will
0052 clear the entire bulk in buffer. It would be possible to read the
0053 maximum buffer size to not run into this error condition, only extra
0054 bytes in the buffer is a logic error in the driver. The code should
0055 should match reads and writes as well as data sizes. Reads and
0056 writes are serialized and the status verifies that the chip is idle
0057 (and data is available) before the read is executed, so it should
0058 not happen.
0059 - Running x86_64 2.6.24 UHCI under qemu 0.9.0 under x86_64 2.6.22-rc6
0060 with a OHCI controller, ds2490 running in the guest would operate
0061 normally the first time the module was loaded after qemu attached
0062 the ds2490 hardware, but if the module was unloaded, then reloaded
0063 most of the time one of the bulk out or in, and usually the bulk in
0064 would fail. qemu sets a 50ms timeout and the bulk in would timeout
0065 even when the status shows data available. A bulk out write would
0066 show a successful completion, but the ds2490 status register would
0067 show 0 bytes written. Detaching qemu from the ds2490 hardware and
0068 reattaching would clear the problem. usbmon output in the guest and
0069 host did not explain the problem. My guess is a bug in either qemu
0070 or the host OS and more likely the host OS.
0071
0072 03-06-2008 David Fries <David@Fries.net>
