On Thu, 12 Apr 2007, Danny Budik wrote:
> On Apr 12, 2007, at 6:25 PM, Alan Stern wrote:
>
> > On Thu, 12 Apr 2007, Danny Budik wrote:
> >
> >> Would it be possible to add my own constant to /usr/include/linux/
> >> usbdevice_fs.h and write an underlying function that would call
> >> usb_get_current_frame_number()? It
> >> looks like I can add a constant say USBDEVFS_FRAMENUM in
> >> usbdevice_fs.h, add new case to .../drivers/usb/core/devio.c, add a
> >> function called proc_framenum
> >> that would call usb_get_current_frame_number() and return the frame
> >> number. Is this a reasonable and/or feasible solution?
>
> Below is a patch to do this but I am new to Linux kernel development
> area. Since this modifies a core usb driver, it's not compiled as a
> module rather into the kernel itself. So, is there a way for me to do
> the following without recompiling the kernel: 1) compile the driver
> by itself and 2) test the functionality of the driver with my user
> space program? Do I have to recompile the whole kernel every time I
> make a modification?
Depends what you mean. The kernel-build system is smart enough to
recompile only the files you have changed (and those that depend on them).
If what you changed is in a module instead of built into the main kernel
binary, then only that module needs to be rebuilt. Then you can rmmod the
old module and insmod the new one without even rebooting.
> Again I'm a newbie, so if you could point me to a good resource on
> how to do this I'd greatly appreciate it.
You can start by reading the book Linux Device Drivers (3rd edition),
which is freely available on the web. You should also read the
instructions in the kernel source file Documentation/SubmittingPatches.
> Thanks,
> Danny
>
>
> linux-source-2.6.17/drivers/usb/core/devio.c
> 812a813,826
> > static int proc_getframenum(struct dev_state *ps, void __user *arg)
> > {
> > int frame_number;
> > struct usb_device *dev = ps->dev;
> >
> > frame_number = usb_get_current_frame_number(dev);
> >
> > if (put_user(frame_number, (int __user *)arg))
> > return -EFAULT;
> >
> > return 0;
> >
> > }
> >
> 1544a1559,1564
> >
> > case USBDEVFS_GETFRAMENUM:
> > snoop(&dev->dev, "%s: GETFRAMENUM\n", __FUNCTION__);
> > ret = proc_getframenum(ps, p);
> > break;
> >
This patch won't compile properly because USBDEVFS_GETFRAMENUM isn't
defined anywhere. Also, you might want to consider returning the frame
number directly as the result of the ioctl instead of passing it through a
user pointer. I don't know which approach is preferred.
On Thu, 12 Apr 2007, Steve Calfee wrote:
> >>Also bear in mind that high-speed buses use microframes rather than
> >>frames; they increment eight times more quickly.
> Hi Alan, that is not right. See USB 2.0 spec 8.4.3.1 USB Frames and
> Microframes
>
> Where it says:
> <quote>
> High-speed devices see an SOF packet with the same frame number eight times
> (every 125 μs) during each
> 1 ms period. If desired, a high-speed device can locally determine a
> particular microframe ^Snumber^T by
> detecting the SOF that had a different frame number than the previous SOF
> and treating that as the zeroth
> microframe. The next seven SOFs with the same frame number can be treated as
> microframes 1 through 7.
> </quote>
Well, it's a matter of your point of view. What I wrote _was_ correct, in
the sense that high-speed buses do indeed use microframes which last only
125 us. However it is also true that the value broadcast at the start of
each microframe is only the frame number, not the microframe number.
> I guess the USB 2.0 spec designers did not see any use for a number that
> changed every 125 usec, and where the field would roll over every 1/4
> second instead of every 2 seconds.
I guess so.
Adding more complexity to the mix, the value returned by ehci_get_frame()
is incorrect for two reasons:
It is taken modulo ehci->periodic_size instead of modulo 2048.
It is derived from the frame_index register of the EHCI
controller, which is out of phase by 1 with respect to the
frame numbers transmitted on the bus. See section 4.5 of the
EHCI spec.
Alan Stern
-------------------------------------------------------------------------
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
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
