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