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
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, an
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) s
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 sysca
On Tuesday 24 May 2011 23:19:27 Jim Bryant wrote:
> the only thing in the usb framework using the cdevsw framework seems to
> be usb_dev.c, but it seems to be an abstraction, and not an end-device
> in the sense that i'm doing.
Hi,
This framework is for USB devices only and can create any chara
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 the
