(and more
> versed in UHCI internals) could contact VIA and get the necessary info.
I would think so; I haven't seen any fixes in the linux stuff yet. Maybe
I'll see about doing some poking around on the net for the issue.
Matthew Fredrickson
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
On Thu, 14 Feb 2002, Georg Acher wrote:
> On Thu, Feb 14, 2002 at 09:54:58AM -0600, Matthew Fredrickson wrote:
> >
> > I just did some testing with the kernel I upgraded to a little bit ago
> > (2.4.17), and have some improved results. I now get basically the same
>
anh OHCI controllers available.
I've already tried it with an OHCI chipset. It works perfectly. I'll
have to hunt around to see if I can find an intel UHCI chipset to try it
on. We don't have any around the office that I know on.
Matthew Fredrickson
_
there's a gap in the audio, I get a printk that says:
usb-uhci.c: iso_find_start: gap in seamless isochronous scheduling
(This is on the VIA chipset UHCI controller)
Does this help any?
Thanks,
Matthew Fredrickson
___
[EMAIL PROTECTED]
To unsubscribe
ut in, so if this
> > seems incomplete, or you have any questions, feel free to reply :-)
>
> JE
Thanks for replying. I hadn't submitted a bug report or anything like
that partly because I've been pretty busy, but mostly because I wasn't
sure what could be done about
On Thu, 14 Feb 2002, Georg Acher wrote:
> On Wed, Feb 13, 2002 at 05:33:13PM -0600, Matthew Fredrickson wrote:
>
> > More data: IIRC, on the vanilla uhci.c driver, ISOC sucks. Sucks really
> > badly. Kind of funny though, 'cause I was helping somebody with writing a
&
my
device. Probably some timing issue in the driver somewhere.
Anyway, hope this helps. By the time I get done with emails like this, I
always seem to forget something important I intended to put in, so if this
seems incomplete, or you have any questions, feel free to reply :-)
Matthew
, mem_base, id);
+ res = hc_found_ohci (dev, dev->irq, mem_base, id);
+ if (res < 0) {
+ iounmap(mem_base);
+ release_mem_region(mem_resource, mem_len);
+ pci_disable_device(dev);
+ }
+
+ return res;
+
+
}
/*---
}
> >>
>
>
> I suspect this part is an OOPS waiting to happen - better
> not kfree(ohci) until after pci_free_consistent(...), I think.
Ugh. I don't know what I was thinking when I did that part. What's the
proper methodology for patch resubmission? Just fix an
iounmap(mem_base);
+ release_mem_region(mem_resource, mem_len);
+ pci_disable_device(dev);
+ }
+
+ return res;
+
+
}
/*-*/
@@ -2890,3 +2912,4 @@
MO
This is a patch against the stock 2.4.17 usb-uhci.c file. It causes some
allocated memory regions to be cleaned up, pci cleanup stuff, etc. In
essence, if your usb-ohci driver fails somewhere in the probe, it cleans
itself up enough so that you can do some more testing to the driver
without havi
on somewhere?
I personally think it's ok; It's kind of nice to see whether or not our
particular patches went in.
I just view and/or grab the patches straight off the list anyway, so I'm
not terribly concerned about an posting them to a site some
the
> Quicknet x-jack cards)
Sorry, I was looking at it from a more personal perspective. If I wrote a
driver for it, it would be for the Zapata Telephony Interface, and I can't
talk g.723.1 to the ZTI.
Matthew Fredrickson
___
[EMAIL PROTECTED]
nvenience this thing could be. The simple part would be the driver. The
hard part would be talking to the device in a language it understands
(G.723.1)
Matthew Fredrickson
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.so
14 matches
Mail list logo
