excuse me while i pull my head out of my posterior...
yup.
it wasn't DRIVER_MODULE() doing it... it was the usb_fifo_attach
i think i'm back on the right track now... thanks for pointing me in
the right direction.
Hans Petter Selasky wrote:
Hi,
On Wednesday 25 May 2011 21:02:29 Jim
do start_read/stop_read and start_write/stop_write map directly to the
userland read(2) and write(2) calls?
i had looked at this previously, and am a bit confused on if the above
is correct.
even if they are the direct interface to read(2)/write(2), the issue of
a poll method for select(2)
Hi,
On Wednesday 25 May 2011 21:02:29 Jim Bryant wrote:
do start_read/stop_read and start_write/stop_write map directly to the
userland read(2) and write(2) calls?
No, but they are called from these calls. The idea is that you use the FIFO
mechanism already present there when moving data, and
i'm in the process of both learning the driver interface and writing a
usb driver for a multimedia product.
i'm kind of stuck here, as i'm seeing two distinct, and possibly
mutually exclusive interfaces here.
the test framework i'm currently using is the DRIVER_MODULE macro, but
it lacks
On Tuesday 24 May 2011 23:19:27 Jim Bryant wrote:
if i add such an interface to the current DRIVER_MODULE version, how
would i go about NOT having DRIVER_MODULE create the devfs entries? i
would prefer to have the devfs entries handled by make_dev, so to have
access to the desired
