Re: libQMI - developed and extended….
nietzsche at lysator.liu.se
Mon Oct 24 09:07:07 PDT 2011
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.
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
More information about the libqmi-devel