Re: libQMI - developed and extended….

[Markus Gothe]

24 okt 2011 kl. 16:35 skrev Dan Williams <dcbw at redhat.com>:

> On Sun, 2011-10-23 at 16:50 +0200, Markus Gothe wrote:
>> Last night I sat up hacking at the GobiDrivers and figured out a way to speedup the probing of modems (and some other tweaks)... By whitelisting the EPs for the specific VID (& PID)... Pretty much inspired by the option and sierra-net drivers. Now from taking a very long time on probing non-Gobi-modems it's is blazing fast. ;-) Apparently I applied the endian-fixes correctly, but one thing bothers me... the MEID. What is it and how is it represented. I know it is like 14 bytes. (Fixing that to be endian-wise will make me go crazy on bit-operations ;-) )...
> 
> It's the Mobile Equipment Identifier, which is the CDMA equivalent of
> the IMEI that GSM/UMTS/LTE use.  All devices that support CDMA/EVDO will
> have an MEID.

This explains things well I'll make a function for arbitrary length (read: slow) byteswapping...
> 
> But good work on making that part faster, the code there does a lot of
> stuff it doesn't really need to do...
> 
> In the end though, a lot of the device detection code in there is
> completely bogus.  What the process *should* be is to grab the port's
> kernel driver name via udev, and if the device is driven by qcserial or
> qcnet (when that ever gets merged), then handle it.  The code does a lot
> of sysfs parkour that could be completely eliminated by just talking to
> udev instead.

Will udev is nice it doesnt fit into the embedded industry where the memory footprint is thight. I suggest keeping the old way and implement udev and use an #ifdef to define which method to use.

The option driver works instead of Gobiserial hanging the kernel.

> 
>> Elly, I see in the Chroniuom src that you've replaced the khtread with a workqueue. What's the reason for this and not using a tasklet?
> 
> That I'm not 100% sure about.

All I know is that the kthread polling is dead slow on embedded systems: Think 200MHz RISC CPU. Maybe I will have to do some inline asm... However the issues we experienced with unloading the driver was fixed by my optimization.

//Markus
> 
> Dan
> 
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel