Re: where to get info to write basic usb driver for own device?

2004-07-08 Thread Rita Lin
I would read up some code in /dev/usb and see how others did theirs.
I would also read the Dynamic Kernel Linker by Andrew Reiter
http://www.daemonnews.org/200010/blueprints.html, and the white paper by zep
software
http://www.zepsoftware.com/whitepapers/bsd_devtree.php.

That's how I wrote my first USB driver.

Rita

- Original Message -
From: Zera Holladay [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 08, 2004 1:11 PM
Subject: Re: where to get info to write basic usb driver for own device?


 This may go without saying, but have you read Chapter 22 of the FreeBSD
 Developers' Handbook?  I have not read intro(4) extensively but that is
 probably a good starting place, if you are completely in the dark.

 -Zera Holladay




 On Sun, 4 Jul 2004, Avleen Vig wrote:

  On Sun, Jul 04, 2004 at 12:53:39PM +, [EMAIL PROTECTED] wrote:
   So what I guess what I am asking is how hard would this be? (I have a
   reasonable knowledge of C and Java and have been using FreeBSD for a
   couple of years but have never written a device driver (for any OS))
Do I
   actually need to write a driver or can I use something already
existing?
   Where would I get information on how to do this?  So far I've been
looking
   at the existing drivers; ugen, ufm etc., the programmers handbook and
am
   starting to look at libusb...?
   Sorry for the long message.  Any pointers etc. would be greatly
   appreciated.
 
  I am actually in a similar situation.
  I know some C, and want to write a device driver for a USB device (web
  cam), but I have no idea where to start.
  I've searched for a beginners guide to writing device drivers but
  failed miserably :-(
 
  --
  Avleen Vig
  Systems Administrator
  Personal: www.silverwraith.com
  EFnet:irc.mindspring.com (Earthlink user access only)
  ___
  [EMAIL PROTECTED] mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
  To unsubscribe, send any mail to
[EMAIL PROTECTED]
 

 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Is it possible to lose a xfer request queued using usbd_transfer()?

2004-05-05 Thread Rita Lin
Hello,

I stumbled on a problem that I need some suggestion to continue tracking
where the problem is.
I started a tip session to the usb port, after typing two characters, any
more input returned TS_BUSY.
I noticed that this problem also exists when I do a 'cat junk  /dev/ucom0'.
After two consecutive usbd_transfer(), it sits there.

After some code tracking, I found that the ucomwritecb() for the third
usbd_transfer() never gets called in uhci_idone(). I haven't dig further
down yet. I'm going to do that tomorrow. If you have some idea, or have some
suggestion how I can tackle this problem, please shine some light on me. The
first two usbd_transfer are successful, and I could see the packets going
out to the USB port with a USB analyzer.

Thank you so much.
Rita

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Is it possible to lose a xfer request queued using usbd_transfer()?

2004-05-05 Thread Rita Lin
TYPO --dig-- should be *dug*.
- Original Message -
From: Rita Lin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 05, 2004 5:39 PM
Subject: Is it possible to lose a xfer request queued using usbd_transfer()?


 Hello,

 I stumbled on a problem that I need some suggestion to continue tracking
 where the problem is.
 I started a tip session to the usb port, after typing two characters, any
 more input returned TS_BUSY.
 I noticed that this problem also exists when I do a 'cat junk 
/dev/ucom0'.
 After two consecutive usbd_transfer(), it sits there.

 After some code tracking, I found that the ucomwritecb() for the third
 usbd_transfer() never gets called in uhci_idone(). I haven't dig further
 down yet. I'm going to do that tomorrow. If you have some idea, or have
some
 suggestion how I can tackle this problem, please shine some light on me.
The
 first two usbd_transfer are successful, and I could see the packets going
 out to the USB port with a USB analyzer.

 Thank you so much.
 Rita

 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: USB device driver question: timeout() and usbd_do_request()

2004-05-03 Thread Rita Lin
 But I don't understand the whole issue you have.
 Just schedule a request and wait for the device to ack.
 The Host controller does the polling for you as long as the request is
 queued and the timeout value supplied with the request did not time out.
 That has nothing to do with FreeBSD - it's how things work with USB in
 general.
I needed a task or a timer that periodicaly polls the modem status from
the USB device.
I think you meant the timeout value inside the usbd_do_request(). I needed
something that
periodically calls usbd_do_request().

The mention of FreeBSD device polling was something I found on the Web. The
FreeBSD allows network driver to do polling instead of interrupt. The
implementation requires the first interrupt from the device in order to
register the callback for the polling. When I first saw the device polling
support in FreeBSD, I thought I could call usbd_do_request() in the callback
routine. I was wrong.

Mike Silbersack suggested the use of kthread. I added it today, tested it
out, and it works. Thanks, Mike!

By the way, for people who are writing USB drivers that uses ucom support,
you do not need to modify ucom.c to support multiple ports. By doing a trick
in declaring xxx_softc, I was able to create 4 ucom ports with one single
physical device.

Rita

 --
 B.Walter   BWCThttp://www.bwct.de
 [EMAIL PROTECTED]  [EMAIL PROTECTED]


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: USB device driver question: timeout() and usbd_do_request()

2004-05-03 Thread Rita Lin
 Igh - that sounds like a very bad device design then.
 There would have been lots a ways to do in a clean way without
 additional pipes - such as transfering 0 sized packets to trigger a
 status inquiry or by adding status bytes in each packet.
 For what purpose do you need to poll the status in case for this device?
I would not say it's a very bad device design. However, I do agree with you
that there are numerous way to implement it. Most devices generate
interrupts
when there is a modem status change. This particular device does
not support interrupts.

 Yes that's possible as long a you have separate pipes for each channel.
 But if you have separate pipes for each channel then the device could
 use separate USB interfaces as well so you can attach seprate instances
 of your driver as well without doing special handling.
 --
 B.Walter   BWCThttp://www.bwct.de
 [EMAIL PROTECTED]  [EMAIL PROTECTED]

That is correct provided that xxx_softc is handled correctly, otherwise, you
will end up handling wrong ucom_softc each time when driver specific
routines are called. I didn't do any special handling in my driver methods.

As I mentioned earlier, I only did a trick in declaring the xxx_softc.
ucom_attach() attaches one instance of my driver. I made this comment
because I saw some earlier posts about ucom needed modification to support
multiple ports.

Rita

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: USB device driver question: timeout() and usbd_do_request()

2004-05-03 Thread Rita Lin
 That is what I call a bad design.
 You waste resources because the device designer did not take the
 features he had available.
Okay, I guess so. There are also other minor things that I don't understand
why
the device is implemented the way it is. Since I don't make it,  and I don't
work for
the company that makes it, it's beyond me.

 If this is a device level driver yes.
 But I still think that a device with multiple ports and separate
 pipes per port should also offer multiple USB interfaces.
Are you talking about USB interfaces at software layer or physical layer? I
think I'm confused here.
If it's software layer, yes, the device offers multiple USB interfaces. Each
interface has its own pipes.
But, of course, the default pipe is shared.

Rita

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


USB device driver question: timeout() and usbd_do_request()

2004-05-02 Thread Rita Lin
Hello,

I'm writing a USB driver for a device that does not have any interrupt. It only has 
Bulk-in and Bulk-out. A periodic polling status from default pipe is required to have 
a smooth data transfer. I used timeout() routine to call usbd_do_request() for 
polling. I thought maybe timeout() is called under interrupt context, since 
usbd_do_request() access system I/O, it crashes. However, by adding this timeout() in 
ucomstart(), it didn't crash until the third call to timeout(). Removing 
usbd_do_request() allows the timeout() to work without any problem. From the USB 
analyzer, I could see that even if the system crashed, a request was sent to the USB 
device correctly. There are two crashdump messages printed out to the screen, I could 
only catch the second one. The first one scrolled off the screen too fast. By counting 
the byte and the instruction pointer, the routine crashed in acquire_lock(). I 
'greped' the kernel source code, didn't see this routine.

I know I'm missing some important FreeBSD concept since I'm new to it, by reading 
related document did not reveal anything that might help me. If usbd_do_request() 
should never be used in timeout() as a callback routine, what other options do I have, 
to implement a status-polling scheme? 

Thank you very much in advance.
Rita
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]