David Brownell wrote:
> As was discussed a few weeks back, this moves most of the
> sanity checks and input conditioning for the HCD framework's
> usb_submit_urb() support directly into usb_submit_urb(), so
> that all HCDs (not just those using the sharable HCD framework
> support) can rely on th
Hi,
my latest version of the isp1161 driver is 0.9.5 (form Octobr 2001).
It is still experimental. (some Bugs ISOC transfers not tested)
Regards
Roman
Roger Barraud wrote:
>Hi Wolfgang et alia,
> I'm (hopefully) most of the way thru porting the 0.8 patch from the
>sourceforge site to P
Dan Streetman wrote:
>On Tue, 26 Feb 2002, Roman Weissgaerber wrote:
>
>>>- I'd suggested that the bandwidth would stay scheduled until
>>> after an interrupt transfer completed, there was no transfer
>>> queued.
>>>
>>If I understand
David Brownell wrote:
>>If INTs could be queued, there would not really even be a need to
>>'resubmit' the URBs. The completion handler can simply resubmit a
>>completed URB (if desired) without any loss of data or polling time.
>>
>
>For the record, this is going down the path of the "support
>
David Brownell wrote:
>
>GOAL: support INTR-OUT and INTR-IN transfers with
>one API model which could also be used for a device
>controller API using an URB-like model.
>
>
>CURRENT MODEL: all interrupt transfers are specified
>with using an URB with transfer_buffer_length set to a
>fixed packe
Hi,
hm, I think the allocation of the TDs has to be changed too.
regards
Roman
Oliver Neukum wrote:
>Hi,
>
>this is for usb-ohci.c
>
> Regards
> Oliver
>
>--- drivers/usb/usb-ohci.c.pre Sun Feb 3 10:28:31 2002
>+++ drivers/usb/usb-ohci.c Sun Feb 3 10:39:56 2002
>@@ -
Hi Tim,
dl_done_list() with
++(urb_priv->td_cnt) == urb_priv->length)
is just for the special case where the URB would have
been finished at the same time we have request the usb_unlink_urb().
Normally dl_del_list() should do the work.
- Roman
Tim Connors wrote:
>To all,
>
>Thanks for the
Benjamin Herrenschmidt wrote:
>Hi !
>
>We used to have the following patch in the PPC tree for ages, could
>someone confirm if it makes sense or not, and if yes, can the maintainer
>send it to Marcelo ?
>
It does not make sense for struct ed (it just makes sense for td).
- Roman
>
>Regards,
>Be
Adam J. Richter wrote:
>>Bad patch. The devrequest struct needs to be in DMAable memory, and the
>>kernels stack isn't DMAable on all arches.
>>
>
>>usb-storage is broken that way... it's on my TODO list, too...
>>
>
>>Matt
>>
>
> Thanks for catching this so quickly.
>
> I conseq
Hi,
enclosed is a new experimental version (0.9.5) of the
isp1161 USB HCD for linux. It includes ISOC (untested) support
and dynamic number of packets per URB/frame support. Also
(untested) support for dynamic interrupt enable/disable.
All untested features are undefined (#undef ...) so if you wan
Hi Chris,
thanks for the error report.
There seems to be a missing ep_unlink() somewhere
(or the ep_unlink doesn't really unlink every ed,
or there is a race between ep_link and ep_unlink).
So we have to find the place where the unlink is missing ...
thanks
Roman
Parrott, Chris wrote:
> Gree
Nemosoft Unv. wrote:
> Greetings,
>
> On Tuesday 30 October 2001 00:20, [EMAIL PROTECTED] wrote
>
>>Hi David, Nemosoft,
>>
>>First of all thanks for your answers. I hope we can get to the bottom of
>>this weirdness!
>>
>>I applied the patch to pwc-if.c and enabled CONFIG_DEBUG_SLAB. I hope the
red new driver pegasus
> pegasus.c: eth1: Linksys USB100TX
> usb.c: registered new driver usbnet
>
> I have also turned on hc_error_verbose and posted my bootup output here:
>
> ftp://ftp.nevus.org/pub/hcd116x/usb_full_debug.txt
>
> My modified source is in that same directo
Brad Hards wrote:
> Bill Ryder wrote:
>
>>Tony Battersby wrote:
>>
>>>
>>>Thanks for the tip. I set a number of port options using tcsetattr() and it no
>longer
>>>panics. My problem is now solved, but the kernel panic should still be fixed.
>>>
>>I think I know what it is thaxn to the good d
ysun wrote:
> Hi There,
> I try to port 2.4.9 ohci driver to a mips platform. I have following
> questions, could anyone kindly clear me?
> 1. Every ED has a dummy TD. Will this dummy TD be processed by HC and put
> into done queue? There is no data in the TD.
The dummy TD will be used for the
Martin Diehl wrote:
>
> On Thu, 11 Oct 2001, Jean Tourrilhes wrote:
>
> > The good news is that your code works beautifully on my box
> > for usb-ohci and usb-uhci. So, it will go out in the next rev os the
> > driver (I also want to try with an XNTD dongle).
>
> Fine, thanks. Chances are
"Mark S. Mathews" wrote:
>
> Hi Folks,
>
> I'm currently working on adding USB support to linux-wlan-ng for the
> Intersil Prism 2.x wireless LAN adapters and I'm having a few
> difficulties.
>
> First and foremost, it seems that the device refuses to drop into it's
> final, configured, mode of
Jean Tourrilhes wrote:
>
> Hi,
>
> I've got a questions for the USB gurus... What is the minimum
> or typical round trip time of a USB bulk transfer ?
> (BTW, I'm not on the list...)
>
> Let's take an example...
> My driver has 2 bulk pipes, in and out. T
Hi,
enclosed is a new version (0.9) of the isp1161 HCD.
It still lacks ISOC transfers but there are some
bug fixed (thanks to Benjamin Herrenschmidt) and
some additional (maybe untested) features like
URB-timeout, Bulk 0-packet,...
regards
Roman
hc_isp1161-0.9.tar.gz
Li Yi wrote:
>
> Sorry, Ben,
>
> The LR register store the instruction which will be executed later, so
> it's memcpy cause the Oops. But you already check the hp->units_left,
> so it should not be ATL buffer overflow.
Have you changed something in the hc_add_trans function
(e.g the len calcula
Hi Alan,
the following patch of usb-ohci.h
which is part of your patch-2.4.9ac18
is wrong.
EDs always has to be 16 Bytes alligned. So
__attribute((aligned(16))); is ok for EDs.
TDs hast to be 32 Byte alligned for ISOC
so the comment should stay there.
Please remove the whole patch for usb-ohci
Benjamin Herrenschmidt wrote:
>
> >Benjamin Herrenschmidt wrote:
> >The one packet is a limitation of v0.8. But you can change it to
> >a larger number e.g. 4 or 8 (max 19) by replacing the 1s in
> >hc_add_trans()/hc_isp116x.c
> >
> >- if (len > maxps *1)
> >-len = maxps * 1;
> >+ if (len >
Benjamin Herrenschmidt wrote:
>
> Ok, Back to USB hacking.
>
> I didn't reproduce my USB host disconnect problem after fixing a
> problem with the IO timings on the CPU bus to the controller.
>
> However, I noticed another issue. I tried plugging an USB mass storage
> device and experienced ver
You should use kmalloc to allocate dma-able ram for the buf buffer.
- Roman
kevin wrote:
>
> Greg KH wrote:
> >
> > On Thu, Sep 20, 2001 at 06:09:52PM -0400, kevin wrote:
> > >
> > > Now I have to send a series of about a dozen vendor specific commands
>
> >
> > Posting exact code might
int val = 0;
>
> outw (regindex, hp->hcport + 2);
>
> for (i = 0; i < length; i += 2) {
> val = inw (hp->hcport);
> buffer [i] = val;
> buffer [i+1] = val >> 8;
> }
> if (length & 1) {
> val = inw (hp->hcport);
> buffer [length - 1]
gt;hcport + 2);
>
> for (i = 0; i < length; i += 2) {
> val = inw (hp->hcport);
> buffer [i] = val;
> buffer [i+1] = val >> 8;
> }
> if (length & 1) {
> val = inw (hp->hcport);
> buffer [length - 1] = val;
> }
> }
>
> Roman W
Hi,
this patch from Jean Tourrilhes adds USB_ZERO_PACKET flag
support to usb-ohci.c. Please forward it to Linus.
Thanks
Roman
Jean Tourrilhes wrote:
>
> On Wed, Sep 19, 2001 at 03:42:18PM -0700, jt wrote:
> >
> > I did a quick read in the source to see if I could implement
> > ZERO_PA
Hi Jean,
can you test the attached modified patch please.
If it is OK we can forward it to
JE/Linus.
Thanks
Roman
Jean Tourrilhes wrote:
>
> On Wed, Sep 19, 2001 at 03:42:18PM -0700, jt wrote:
> >
> > I did a quick read in the source to see if I could implement
> > ZERO_PACKET. Well,
Jean Tourrilhes wrote:
>
> On Wed, Sep 19, 2001 at 03:42:18PM -0700, jt wrote:
> >
> > I did a quick read in the source to see if I could implement
> > ZERO_PACKET. Well, let's just say that it's not as simple as I
> > tought. TD are done multiple of 4096, which doesn't fit with the code
>
David Brownell wrote:
>
> > Now the HCDs can use endpointnumber+direction(pipe) as
> > an index for the endpoint descriptor array and get all the
> > information about the endpoint from there.
>
> ... after updating control flow in some cases to make sure
> they don't separate the usb_device fro
David Brownell wrote:
>
> Roman,
>
> > There are a lot of things that are endpoint specific:
>
> (endpoint in a given config/altsetting ...)
>
> > e.g. maxpacketsize, toggle bit, startingpoint and intervall
> > of INTR transfers, queueingpoint for URBs,...
> > And all that information is sprea
Oliver Neukum wrote:
>
> Am Mittwoch, 19. September 2001 12:05 schrieb Roman Weissgaerber:
> > Oliver Neukum wrote:
> > > > > These are usb_control_message() and usb_clear_halt(). I was thinking
> > > > > of doing a version for block devices that
Oliver Neukum wrote:
>
> > > These are usb_control_message() and usb_clear_halt(). I was thinking
> > > of doing a version for block devices that uses NOIO. Thus compatibility
> > > is maintained in 2.4 and in 2.5 we'd merge and add another parameter to
> > > the call.
> >
> > What did you think
Johannes Erdfelt wrote:
>
> On Tue, Sep 18, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> > So... has anyone thought about what it would take for Linux to support a
> > single URB with multiple scatter-gather elements?
> >
> > AFAIK, an URB needs a single continuous memory block for a transfer
"Wessler, Siegfried" wrote:
>
> Hello,
>
> I just entered this mailing list, so I have no idea what's up right now.
>
> We want to implement communication between two PC via USB. We use Embedded
> Linux (ElinOs and SuSE) to keep Linux running. We got our own ETX platform
> and have placed t
Hi Neil,
OHCI and UHCI are different Host Controller designs
so they are not compatible.
UHCI is from Intel and
OHCI from Compaq, National Semiconductor and Microsoft.
But there is a patch
for the usb-ohci driver for the SA- from Brad Parker.
You can find it in the latest 'Nicolas Pitre
Georg Acher wrote:
>
> Hi,
> I'm currently fighting with the timing in hub.c...
>
> The Polestar USB audio device (with the Philips UDA1321) doesn't work anymore
> with the current hub code (it worked a long time ago), the result after a
> plugin is the usual "USB device not accepting new addres
Mark McClelland wrote:
>
> Georg Acher wrote:
>
> >Hi,
> >I'm currently fighting with the timing in hub.c...
> >
> >The Polestar USB audio device (with the Philips UDA1321) doesn't work anymore
> >with the current hub code (it worked a long time ago), the result after a
> >plugin is the usual "U
David Brownell wrote:
>
> > And I have also found a bug but it seems it's not the 'right' one
> > for this problem:
> >
> > urb_free_priv () just unmaps the last part (belonging to the last TD)
> > of the data buffer.
>
> I'll have to patch that. Clearly I was thinking I made OHCI do
> this the
Umpf, I think I have found the usb-ohci ISOC bug (linux-2.4.5ac7)...
-Roman
--- drivers/usb.org/usb-ohci.h Sun Jun 3 13:49:15 2001
+++ drivers/usb/usb-ohci.h Thu Jun 7 16:09:51 2001
@@ -116,7 +116,7 @@
dma_addr_t td_dma;
dma_addr_t data_dma;
__u32 unused2[2];
-} _
David Brownell wrote:
>
> Since folk have been reporting issues with iso in current OHCI code,
> I've spent a bit of time looking at it:
>
> - I've got "camstream" working fine right now with a CPIA camera
> and OHCI on a slowish (P1/300) laptop ... works fine, no messages.
>
> - Same with th
Mark McClelland wrote:
>
> Norbert Preining wrote:
>
> >On Son, 27 Mai 2001, Nemosoft Unv. wrote:
> >
> >>Here´s another one with short frame buffers on an OHCI controller... Looks
> >>like we have a bug on our hand. Seems to be the same problem as Norbert
> >>Preinings´.
> >>
> >
> >Is there an
"Nemosoft Unv." wrote:
>
> Hi,
>
> Short description of the problem: Norbert can´t use the webcam driver
> because the driver always receives image frames that are too short; it looks
> like a lot of URBs got dumped. Interestingly, the iamge frame length is
> usally constant. We narrowed the pro
Georg Acher wrote:
>
> On Wed, May 23, 2001 at 09:19:07AM +0200, Roman Weissgaerber wrote:
>
> > But then there will be a gap again. At the time the CPU
> > looks at the ->next pointer that next URB should be
> > already queued.
> >
> > !!!URB QUEUEIN
David Brownell wrote:
>
> > Now with queued URBs:
> >
> > - Submit a chain (URB_1, URB_2) immediately to the HCD
> >/* I think we still need to submit both URBs seperately? */
>
> Certainly each "submit" can report errors immediately ... which
> is why I don't quite know what it should mean
Hi all,
I think the main problem with the ->next pointer is that it
is designed without queueuing in mind. But all!!!
transfer types can use some sort of queueing because
we can not guartantee that the CPU can handle a HC interrupt
immediately (and therefore without transfer queueing we get gap
Thomas Sailer wrote:
>
> Roman Weissgaerber schrieb:
>
> > Also if a HCD would use static, typed Endpoint-Descriptors there
> > would be a type mismatch.
> > (OHCI uses different HW-queues for int
> > and bulk transfers so if you mix them there could be some
Thomas Sailer wrote:
>
> Dan Streetman schrieb:
>
> > 2.Polling interval
> > The polling interval for bulk URBs is as-fast-as-possible. The device must
>
> I thought in case of a NAK the HC should wait for the next frame to try again,
> but maybe I'm wrong
>
Where do you read that or why do
David Brownell wrote:
>
> > 2.Polling interval
>
> I don't see why this is a different issue than #3 ... it argues
> that treating interrupt urbs as bulk is incorrect, but that's
> not news.
>
Lets say we have a USB device with a 32ms interrupt endpoint. The
device has data ready at the interru
Thomas Sailer wrote:
>
> Dan Streetman schrieb:
>
> > The URB is not automatically resubmitted by the HCD.
>
> BTW, what is the difference between such a nonresubmitted
> interrupt and a bulk transfer? Unless I'm missing something
> they look exactly the same on the wire, so why add another
> r
Thiruvengada Govindan wrote:
>
> Hi,
>
> The endpoint descriptor has a bit field that indicates whether the
> device attached is a "low speed" or "full speed" device. Now does the
> host controller interpret this field in any or is it ignored. I check
> the OHCI spec and it does not specify what
Brad Hards wrote:
>
> Greg KH wrote:
> > Finally! A device that uses DFU in the wild! About time... :)
> Naturally, the manufacturer couldn't resist a few additions :(
>
> > Yes, we should probably support this, but probably through libusb, not a
> > kernel driver.
> I'm doing a libusb driver
Benoit PAPILLAULT wrote:
>
> Hi,
>
> I must admit I'm not a USB or PCI expert, but here is the pb:
>
> First machine:
> Athlon 800 Mhz
> Abit KT7 RAID mobo (VIA chipset)
> USB Controller: CMD Technology Inc USB0670 (rev 6)
> kernel 2.4.4
>
> Works perfect & great (used with the Alcatel SpeedTo
Vasudev Mulchandan wrote:
>
> Hello !!
>
> We are beginners with USB and currently planning to a fake USB device.
>
> We plan to use a OHCI Adapter on a x86 platform running an RTOS like
> Vxworks/pSOS.
> This would be our device. We are planning to fake a USB Printer device.
>
HI,
If you wan
Sergij Kolisnyk wrote:
>
> - Original Message -
> From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 09, 2001 8:34 PM
> Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
>
> >
> > >
> > > ----- Original Message -
> > > From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, May 09, 2001 4:54 PM
> > > Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
&
Sergij Kolisnyk wrote:
>
> - Original Message -
> From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, May 09, 2001 4:54 PM
> Subject: Re: [linux-usb-devel] EILSEQ - FAQ ??
>
> > Sergij Kolisnyk w
Sergij Kolisnyk wrote:
>
> Hi!
>
> All we know the problem.
>
> On _some_ motherboards when doing USB bulk read at full speed,
> URB completes with "-84" error code...
>
-84 (EILSEQ) means CRC Error of the packet sent by the device.
So I think this is a problem of the device and not of the HC
David Brownell wrote:
>
> > How about a simpler fix? ...
>
> Like the attached patch. This is against 2.4.4 and includes:
>
> - that simpler hashchain patch (no new spinlocks!)
> - what ac5 had (handle more flakey hardware)
> - lots of readl() to flush PCI writes
>
> That readl()
thread will lose the race and the callback
will be called earlier.
- Roman
> - Original Message -
> From: "Roman Weissgaerber" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 13, 2001 3:37 AM
> Su
Kári Davíðsson wrote:
> Hi,
>
> In the m8xxhci.c hci driver for the mpc one can select to use TIMER1 for
> the SOF generator.
> A interruopt handler, m8xxhci_timer_interrupt() is registered to handle
> this interrupt and generate the SOF.
> Why is it then that the timer is also exported to PA6?
>
Hi David,
basically, I like the idea of shared HCI code.
If you want you can see my patches as a step in that direction.
I would expect a common architecture in Kernel 2.5.
But first a short history:
a lot of the changes of the m8xxhci driver I have done in
november and december. I had a seriou
nel_thread(m8xxhci_thread, NULL,
- CLONE_FS | CLONE_FILES | CLONE_SIGHAND);
- if (pid < 0) {
- MOD_DEC_USE_COUNT;
- return pid;
- }
-
-#if TEST_THREAD /* hack */
- pid = kernel_thread(test_thread, NULL,
- CLONE_FS | CLONE_FILES | CLO
Hi Brad,
patch 1 for the MPC850 host driver.
(m8xxhci_mc.c is the optional microcode patch,
if someone needs it)
Roman
--- mpc850/m8xxhci.cWed Mar 14 10:24:45 2001
+++ mpc850p1/m8xxhci.c Wed Mar 14 10:27:13 2001
@@ -121,6 +121,12 @@
#include "m8xxhci.h"
#endif
+//#define INCLUDE_USB_UC
Hi Brad,
now I have some USB bulk devices (USB-storage and pegasus.c (patched))
working with a modified version of your MPC850/823 USB host driver.
(BTW. The MPC850 has some serious hardware problems when used with some
tranceivers.)
As I am useing a TQ Board and there were some problems with bu
Hi Petkan,
there are some races in the pegasus driver.
When you submit an URB please keep in mind that the
callback of the URB can be called earlier than
the URB-submition returns. In this case you wake up the
thread first and than put it to sleep.
This **really** happens on
a CPU time eating H
David Brownell wrote:
>
> For OHCI another way to solve the done_list bus_to_virt isssue:
>
> struct td {
> ...
> struct td *dma_hash;/* grows size 64 -> 68/72 */
> dma_addr_tdma_addr;/* ... 72 */
> };
>
> #define TD_HASH_SIZE53/* prime */
>
Brad Parker wrote:
>
> Steve Longerbeam wrote:
> >
> >--3FD8AC989C7C80185F008685
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >
> >Alan Cox wrote:
> >
> >> > Drivers can keep track of this kind of information themselves,
> >> > and that is what I
Russell King wrote:
>
> I've dropped the linux-kernel list off this. If someone thinks it should
> still be on that list, appologies.
>
> Alan Cox writes:
> > Even if not you can hash by page number not low bits so the hash is way
> > smaller. You (in most cases) can also write the entry number
Hi Andrew,
there is a bit for the connection status of every
port of the root-hubs:
OHCI:
connection = 0;
num_ports = readl (&ohci->regs->roothub.a) & RH_A_NDP;
for ( i = 0; i < num_ports; i++) {
connection |= (readl (&ohci->regs->roothub.portstatus[i]) &
RH_PS_CCS);
}
if(!connection) susp
70 matches
Mail list logo
