Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jun 2003 14:58:28 -0400
From:      "Louis A. Mamakos" <louie@TransSys.COM>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: USB, select/poll for ucom 
Message-ID:  <200306251858.h5PIwSW8017536@whizzo.transsys.com>
In-Reply-To: Your message of "Wed, 25 Jun 2003 10:15:49 MDT." <20030625.101549.78767546.imp@bsdimp.com> 
References:  <imp@bsdimp.com> <E19VCk7-000254-00@cs.huji.ac.il> <20030625.101549.78767546.imp@bsdimp.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> In message: <E19VCk7-000254-00@cs.huji.ac.il>
>             Danny Braniss <danny@cs.huji.ac.il> writes:
> : 
> : > I'm able to use ppp with umodem/ucom.  My brother uses ulpcom/ucom for
> : > his ppp needs.  I'm pretty sure that select is involved. :-)
> : > 
> : > >From what I can see in the code, I'd expect that it would work because
> : > the ttypoll routine is specified for the poll routine.  Why do you
> : > think it wouldn't work?
> : 
> : well, for one, my program doesn't work :-), it works with the RS232 version.
> : 
> : so i started to poke around, and did some reading, and as far as i could tell,
> : the read(2) has to be initiated by the host, but my knowledge of usb is close
> : to zero - it was zero 2 days ago, but still looking for some better docs, and
> : polish my english - as far as i remember interrupt is not polling, but the
> : ohci docs imply that :-)
> 
> have fun.  the mindshare book is good.  however, it took me a long
> time to get a usb 'aha' moment and understand its twisty maze was
> really a workable design obscured by standardese...  I suspect it is a
> problem in the usb chipset driver for the com part.  ttypoll just says
> 'you have data in the buffer' so for some reason the data isn't making
> into the tty buffer.

I think the problem is that the USB hardware doesn't try to read data
from the peripheral until the user-mode code does a read(2) system
call.  I had this problem with the ugen device.  I would guess that
the ucom/umodem devices could use the tty clist infrastructure as
the intermediate buffer for data to be stuck into absent the user
application doing a read.

louie







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200306251858.h5PIwSW8017536>