On Wed, Jan 02, 2002 at 06:42:38PM -0500, Michael H. Warfield wrote:
> Hello all,
>
> The reader that I have is not immediately recognized. It has
> vendor code 0x07c4 and product code 0xa109. As a first order experiment,
> I "cloned" the 0x07c4:0xa005 PNY/Datafab entry in unusual_devs.h.
Oops, forgot to update the documentation. This patch should fix that :)
greg k-h
diff -Nru a/include/linux/usb.h b/include/linux/usb.h
--- a/include/linux/usb.h Wed Jan 2 16:27:11 2002
+++ b/include/linux/usb.h Wed Jan 2 16:27:11 2002
@@ -460,6 +460,7 @@
/**
* struct usb_dri
On Wed, Dec 19, 2001 at 10:31:31AM +0100, [EMAIL PROTECTED] wrote:
> Hi,
>
> this adds module usage count handling during probe and disconnect to the
> usb core. It applies to 2.5.1 and is now in the smallest possible form.
> I did not go at the old style probe, as it shoulde be IMO removed.
Ok,
Hello all,
This is one of my blue moon times when I poke my nose briefly
into USB stuff and raise a ruckus before lurking off onto other things...
I've got at least two past topics I need to revisit, but that will
be for another day...
This time I've been poking at the PNY/datafa
Hi,
Here's a patch against 2.5.2-pre6 that adds Configure.help entries for
all of the new usb drivers, and updates the build files to allow people
to select them.
thanks,
greg k-h
diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help
--- a/Documentation/Configure.help W
Hi,
Here's a patch against 2.5.2-pre6 that adds the USB stv680 video camera
driver. The driver was written by Kevin Sisson. A patch to add the
driver to the build and the Configure.help entry will be sent later.
thanks,
greg k-h
diff -Nru a/drivers/usb/stv680.c b/drivers/usb/stv680.c
--- /
Hi,
Here's a patch against 2.5.2-pre6 that updates the Documentation/usb
directory with new files for the ehci and stv680 drivers, and updates
the usb-serial.txt file with info for the ipaq and kl5kusb105 drivers.
thanks,
greg k-h
diff -Nru a/Documentation/usb/ehci.txt b/Documentation/usb/eh
Hi,
Here's a patch against 2.5.2-pre6 that adds the USB vicam video camera
driver. The driver was written by Christopher Cheney and Pavel Machek.
A patch to add the driver to the build and the Configure.help entry will
be sent later.
thanks,
greg k-h
diff -Nru a/drivers/usb/vicam.c b/drivers
All,
Does anyone know of any good HOW-TOs on writing drivers for linux USB
devices? I'm not on the list, so please mail directly to me. Thanx.
Regards,
Derek R.
--
Linux Technician
713-817-1197 (cell)
713-781-4000 x2267 (office)
"Chihuahuas - Nature's little kickballs"
___
> > > > > I presume there is some overhead in bouncing to lowmem? I imagine that
> > > > > highmem support for the HCDs wouldn't be that difficult -- they are just
> > > > > PCI devices, after all.
> > > >
> > > > I'm unclear on what "bouncing to lowmem" involves, but I'd rather avoid
> > > > tea
> > - EITHER:
> >
> > * each HCD is modified to manage page DMA
> > mappings if needed, in the same places they now
> > handle the single shot DMA mappings
> >
> > - OR:
> >
> > * the (new) hcd layer does this, once. In that case
> > it'd be
On Wed, 2 Jan 2002, Jens Axboe wrote:
> On Wed, Jan 02 2002, David Brownell wrote:
> > > > requirement for drivers is that the transfer buffers can be passed to
> > > > pci_map_single() calls by the Host Controller Drivers (HCDs). The
> > > > device drivers, and URBs, don't expose such mappings,
On Wed, 2 Jan 2002, David Brownell wrote:
> > > > I presume there is some overhead in bouncing to lowmem? I imagine that
> > > > highmem support for the HCDs wouldn't be that difficult -- they are just
> > > > PCI devices, after all.
> > >
> > > I'm unclear on what "bouncing to lowmem" involves,
> - EITHER:
>
> * each HCD is modified to manage page DMA
> mappings if needed, in the same places they now
> handle the single shot DMA mappings
>
> - OR:
>
> * the (new) hcd layer does this, once. In that case
> it'd be advantageous to add
On Wed, Jan 02, 2002 at 10:45:36PM +0100, Nemosoft Unv. wrote:
>
> Please apply.
Added to both my 2.4 and 2.5 trees.
thanks,
greg k-h
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linu
Found on http://www.hexus.net:
-
USB2.0 to ship on Intel and VIA Southbridges in 2002
Posted on Tuesday, January 1, 2002 by Ryszard
An email from a highly trusted source landed in my Inbox with a couple of tasty
tidbits of
information regarding chipsets in 2002.
Firstly, Intel are
Greetings,
Well, time for another update of the Philips (and others) webcam driver.
This patch will upgrade the PWC driver to version 8.5, and includes the
following changes:
* Adding IDs for Creative Labs Webcam 5
* Adding IDs for SOTEC CMS-001 webcam
* Solving possible hang in VIDIOCSYNC whe
On Wed, Jan 02 2002, David Brownell wrote:
> > > OK, I think I'm clear on this much then: in 2.5, to support block drivers
> > > over USB (usb-storage only, for now) there needs to be an addition to
> > > the buffer addressing model in usbcore, as exposed by URBs.
> > >
> > > - Current "transf
OK, so it looks like URBs need to learn about highmem.
Here's a quick proposal. It's rather first-drafty, and needs
discussion (for a week or so?).
- Add to struct urb:
struct page *page;/* [in] transfer buffer page */
unsigned offset;/* [in] offset within page
I have added the Studio PCTV USB SECAM device to the USBVision driver.
Could everyone that has this device test it out.I would like to
confirm the number of channels. You can grab the latest version from
my website. I have also, done some small changes to the driver.
www.emuit.com/we
> > OK, I think I'm clear on this much then: in 2.5, to support block drivers
> > over USB (usb-storage only, for now) there needs to be an addition to
> > the buffer addressing model in usbcore, as exposed by URBs.
> >
> > - Current "transfer_buffer" + "transfer_buffer_length" mode needs to
>
> > > I'd rather eliminate as much overhead as possible -- I already get
> > > complaints from performance fanatics about the inability of usb-storage to
> > > get past 92% bus saturation (sustained), and the problem will only get
> > > worse on USB 2.0
> >
> > Well then you'll be glad to see a p
On Wed, Jan 02 2002, David Brownell wrote:
> > > requirement for drivers is that the transfer buffers can be passed to
> > > pci_map_single() calls by the Host Controller Drivers (HCDs). The
> > > device drivers, and URBs, don't expose such mappings, they only
> > > require that they can be creat
> > requirement for drivers is that the transfer buffers can be passed to
> > pci_map_single() calls by the Host Controller Drivers (HCDs). The
> > device drivers, and URBs, don't expose such mappings, they only
> > require that they can be created/destroyed.
>
> .. which is the requirement that
Hello,
I just got a "Fast Flicks" digital camera, made by Tiger
Electronics. It's a very cheap device and appears to be unsupported by
linux. I know C pretty well and have experience of programming in linux
using gcc, so I'm thinking of writing a driver for this device. The
vendor/produ
Amira Solomovici wrote:
>>What kind of device do you have?
>>
>A SmartCard reader. Are there allocated major:minor numbers for such devices
>(as there are for scanners, for example)?
>
Check out this link: http://www.linuxnet.com/software.html
You'll need to install PC/SC Lite and the appropria
On Tue, Jan 01 2002, David Brownell wrote:
> > > Not that I've seen a writeup about highmem (linux/Documentation
> > > doesn't seem to have one anyway) but if I infer correctly from that
> > > DMA-mapping.txt writeup, URBs don't support it because there's no way
> > > to specify buffers as a "stru
On Tue, Jan 01 2002, David Brownell wrote:
> > > No, you can always ask to get pages low mem bounced. Highmem is no
> > > requirement, and if your device really can't support it there's no point
> > > in attempting to support it.
> >
> > I presume there is some overhead in bouncing to lowmem? I i
On Tue, Jan 01 2002, Matthew Dharm wrote:
> On Tue, Jan 01, 2002 at 11:34:23PM +0100, Jens Axboe wrote:
> > On Tue, Jan 01 2002, David Brownell wrote:
> > > Not that I've seen a writeup about highmem (linux/Documentation
> > > doesn't seem to have one anyway) but if I infer correctly from that
> >
> > I presume there is some overhead in bouncing to lowmem? I imagine that
> > highmem support for the HCDs wouldn't be that difficult -- they are just
> > PCI devices, after all.
>
> I'm unclear on what "bouncing to lowmem" involves, but I'd rather avoid
> teaching all three HCDs a second model
30 matches
Mail list logo
