Bill Marr <[EMAIL PROTECTED]> > > On Wednesday 28 March 2007 12:21am, Mike Isely wrote: > > Bill Marr <[EMAIL PROTECTED]> wrote:
[...] > > 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? Yup, that's the one. > > Actually, I later found a good website comparing the 2 devices: > > http://www.earthmate.com/GPScomparison.asp So, a different GPS chipset, but feature-wise they are similar enough. [...] > > 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 Here's what I get: T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=1163 ProdID=0100 Rev= 0.04 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. > So, yes, my product ID as expected is 0x0100 instead of 0x0200. > 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. Yes, 6ms here. The driver had been hardcoded to poll at 1ms previously and that was the root cause of instability here with my device. As you've probably noticed, one of the patches now causes the driver to use the polling rate reported by the hardware (along with a module option to override it if really desired). [...] > > 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 need to go find the datasheet and really look at this. I think I did look at a datasheet last summer when I did all this - but you're right. If it's the same USB serial converter then it certainly seems as if this serial line settings check should still work! > 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 currently don't subscribe there. So if there's a reply that doesn't cc me, I'd appreciate it if you forwarded that. [...] > > 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. > Well one datapoint here is that I was running an old 2.6.10 kernel for quite a long time before moving up to 2.6.17. I don't think I ever successfully ran that driver with any patches as recent as 2005-05-17 until I moved up kernel versions. Maybe Lonnie got an LT-20 later and then never regression tested his changes against the old version of the device? [...] > > 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. I agree. The instinctive fix will probably work, but I don't think we understand the true root cause here yet. It could very well be that the driver is doing something bad to get the serial line settings and that theoretical benign problem just becomes malignant with more recent hardware. [...] > > 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. You know now that you mention it, I think I remember noticing that as well. But I didn't make any attempt to change / fix this since it didn't appear to be causing any harm (at least not for me). > > 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 will bang on some brain cells here and refresh my memories of this from last summer. When I did these patches by the way, I first pulled the driver into a local SVN repository, complete with diffs marked for every change I could vacuum up. So I should have a good trail of the changes here. > > 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! As I mentioned before, I was going for (hopefully) just surgical changes. I wasn't trying to analyze and fix every strange thing I saw - just the ones that were obviously causing problems. Maybe we should do some refactoring on this thing. > > 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)? I'm pretty sure it was returning reasonable results. If it wasn't I think I would have noticed and then dug deeper. But I'll have to retest to be sure. It's been too long. > > 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 will refresh my memory on this driver hopefully this weekend. [...] > > 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. That is an *excellent* technique to follow. I've done that a lot in my work to get my pvrusb2 driver going. [...] > > Thanks again for your insight and assistance, Mike! I think we can come to a > good working solution for this driver. You've got me thinking about this again. I'm definitely going to revisit this code and see what else I can dig up :-) -Mike -- | Mike Isely | PGP fingerprint Spammers Die!! | | 03 54 43 4D 75 E5 CC 92 | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | | ------------------------------------------------------------------------- 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
