On Wednesday 28 March 2007 12:21am, Mike Isely wrote: > Bill Marr <[EMAIL PROTECTED]> wrote: > > [...] > > > However, I'm still left wondering what your actual device is that uses > > the 'cypress_m8' module. > > It's a DeLorme Earthmate GPS; no "LT-20" however.
Ah, OK... good. I didn't realize they had a pre-"LT-20" USB version. All I could recall was a really old (bulkier) thing called "TripMate" (RS-232?). I'm going to guess that your Earthmate (and the markings on it) look exactly like this: http://www.amazon.com/Earthmate-GPS-Street-Atlas-USA/dp/B00008WMJ9 True? Actually, I later found a good website comparing the 2 devices: http://www.earthmate.com/GPScomparison.asp > This is a matchbook > sized device and I believe it was their first version of the USB GPS > receiver. Probably just an earlier version of what you have. I'm pretty sure you're right. I have 2 of them (both "LT-20", purchased about 10 months apart) and they both report like this: T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1163 ProdID=0200 Rev= 0.01 S: Manufacturer=DeLorme Publishing S: Product=DeLorme USB Earthmate C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=cypress E: Ad=81(I) Atr=03(Int.) MxPS= 32 Ivl=6ms E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl=6ms I (foolishly) hadn't noticed it earlier, but 'cypress_m8.h' shows 2 different product IDs for the 2 USB-based Earthmate GPS receivers. Mine reports 0x200 as you can see above, so I suspect (please confirm) that yours reports 0x100. In fact, in case it matters, could you please report the appropriate portion of the content of your 'cat /proc/bus/usb/devices' output sometime? From your patch submission comments, it sounds like your 0x100 device also reports 'Ivl=6ms', but I'd like to be sure so I'm interested in the whole (Earthmate GPS -related) output too. I think that, once we confirm that the LT-20 (0x200) models are truly incapable of replying to the 'CYPRESS_GET_CONFIG' query, this problem could easily be solved with a simple branch based on the check of the vendor/product ID. Update: More on this below, after serious testing was done.... > It is > USB powered and has a single tiny LED which blinks green when it has a > GPS lock and blinks red when it is acquiring a lock. Same with my LT-20. > > As near as I can see, the Earthmate LT-20 GPS will never pass that check > > and, like the 'cypress_m8' driver did before your patch (and does now, > > after my "patch"), it should not call 'cypress_set_dead()' at all at that > > particular point. It should just report the problem (as it did then and > > does now [2.6.19]) and continue (as it did then). > > It passes that retrieval step just fine here. (However admittedly I > haven't tried to use the GPS since early 2.6.19; just haven't done any > road tripping since then.) This (the fact that your 0x100 product passes and my 0x200 doesn't) is the most interesting part of the whole thing. I can't quite figure out why. I'd be surprised if the Cypress chipset changed that much between such otherwise-similar devices, but, I suppose, stranger things have happened. > Seems like the answer here is to find out why an attempt to retrieve > serial line settings on your device fails. Agreed. I was half-heartedly hoping that at least 1 other Earthmate GPS user would have some input by now, but I suppose I should have included the 'linux-usb-users' mailing list instead of just the '-devel' list. To remedy that, I've opened a new thread on the 'linux-usb-users' list to see if someone else might have extra input. > > I'm a bit puzzled because, IIRC, Lonnie Mendez created the 'cypress_m8' > > driver specifically for the Earthmate LT-20 GPS. Am I the only one having > > trouble with that GPS and the newer (2.6.19 and later kernels) > > 'cypress_m8' module? > > Well I'm not sure I agree with your direct assessment. Maybe he > tested later with an LT-20 (I have no real idea), but my impression is > that this driver was targeted to the DeLorme Earthmate GPS, which > includes my device, and I think he started it (but I'm not sure) > before the LT-20 variant appeared. Upon reflection (and a check of his website), I think you're right. His website (http://geocities.com/i0xox0i/) clearly shows that he has the earlier 0x100 product ID. It looks like a 2005-05-17 patch by Lonnie added support for the LT-20 variant. Sorry for the confusion. Of course, that raises the question: How could the original driver work for Lonnie and not for you, since you both appear to have the 0x100 product? I realize that there were things broken in the driver (bad error code checking) that your patch fixes, but I still can't figure out how that original driver worked for any 0x100-product users (e.g. Lonnie) when it was so broken for you. > > I just wanted to report this to you and to the 'linux-usb-devel' list in > > case a fix which is more elegant than my quick hack could be made. Not > > knowing what device you're using, maybe just a specific device check at > > that point would suffice? > > I will look again at the driver and see if I can make that failure > recovery a little less of an elephant gun. Then we'll both be happy. > That being the case, I would like to enlist your help trying some > tests and comparisons between our devices. I'll gladly help. In fact, now that I know your device is an earlier variant of the Earthmate USB GPS, I'd say the onus of fixing the driver may rest as much or more on my shoulders as it does on yours. :^) > Let me know if you are willing to dig deeper into this. I am definitely willing to dig into this. My instinct was to just add the vendor/productID-based check I mentioned earlier, but I wanted to "probe" a bit first, just to see if I could characterize the problem just a bit better. So I took time to look into this whole issue some more by trying all sorts of things to make my LT-20 properly respond to the request to report the serial port settings. Nothing I did would make the device respond. I grabbed as much data from the Internet on the Cypress CY7C64013 chip that I could find. I tried all sorts of permutations of the subfields in the 'bmRequestType' field of the USB Device Request sent to the control endpoint. Nothing I tried would make the LT-20 respond properly, though. Incidentally, I don't know why the driver attempts to read 8 configuration bytes (referred to as the "Feature Report" in some Cypress docs) from the Cypress device when it only has 5 to offer. For a minute, I thought that might be causing the problem, but when I changed it from 8 to 5, it made no difference. No matter what I do, I get '-EPIPE' (-32) on that call to 'usb_control_msg()' (the one with 'HID_REQ_GET_REPORT'). I was able to find some code at the Cypress site which seems to confirm the use of the values 0x01 and 0x09 for 'HID_REQ_GET_REPORT' and 'HID_REQ_SET_REPORT', respectively. So that's reassuring. However, I'm unable to discern a source for the "magic" 0x300 number (the 'wValue' field (as named in the USB spec) in the call to 'usb_control_msg()'. I've resorted (for now) to the simple solution of just checking for the LT-20 device and bypassing the call to query the serial port settings under those conditions. In fact, I really don't know why the serial line settings are queried at all, given that it's done _after_ they're set, with the stated intention (in the code) of being able to check if the settings took hold. However, I see nowhere (might've missed it) where such data is ever used to make such a check! I'd still like to know how your pre-LT-20 GPS behaves on the call to get serial port settings. I know it works for you, but is it really returning the correct data settings? Can you add some debug code to confirm this, (especially since it appears to me as if this call could return garbage and we'd never know it)? If I can come to no better conclusion, I plan to submit a simple patch, which I'll ask you to test first, assuming that's OK with you. Assuming no problems, I'll submit that patch for the next kernel release. > I can take > another look at this driver. It isn't that complex. True. In fact, my one-and-only submitted kernel module patch was for the somewhat-similar 'mct_u232' driver (for various RS-232->USB devices), which I had to fix over 3 years ago to make my Belkin F5U109 converter send commands to my RS-232 Garmin 'GPS35 TracPak' (RS-232) GPS receiver. I wasn't planning on delving that deeply into RS-232/USB interaction ever again, but... too late now! :^) In fact, if I get a bit more time, I'm planning to hook the LT-20 up to a Windows PC and use 'USB Snoopy' to sniff the traffic a bit. Maybe that will shed some light on this whole issue. > However it may > not be until this weekend when I can take a swing at it again. Not a problem. I'll try to work on this some more as soon as I can. Thanks again for your insight and assistance, Mike! I think we can come to a good working solution for this driver. Bill Marr ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
