On Tuesday 28 November 2006 2:10 pm, Larry Fenske XX (BO/EUS) wrote:
> usb 5-1: new full speed USB device using address 2
> usb 5-1: device not accepting address 2, error -71
Can you see if this patch helps?
CUT HERE
Tweak some early enumeration code paths:
- After a
; Oliver
>
> Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> --- drivers/usb/net/gl620a.c.old 2006-11-16 05:03:40.0 +0100
> +++ drivers/usb/net/gl620a.c 2006-11-27 18:29:51.0
On Monday 27 November 2006 8:31 am, Oliver Neukum wrote:
> If it is abandoned code I suggest that it is removed, or if not, that the
> patch be applied, because it will backfire later on.
The patch is wrong, so it should not be applied.
I'd support either fixing the code _the right_ way (as expla
On Monday 27 November 2006 6:51 am, Alan Stern wrote:
> On Sun, 26 Nov 2006, David Brownell wrote:
> > The question still remains: how could this corruption happen?
>
> ...
>
> They share the same cache line as parts of the buffer. As a result the
> cache line get
On Monday 27 November 2006 12:35 am, Oliver Neukum wrote:
> Am Montag, 27. November 2006 04:22 schrieb David Brownell:
> > On Sunday 26 November 2006 6:46 pm, Alan Stern wrote:
> > > On Sun, 26 Nov 2006, David Brownell wrote:
> > >
> > > > On Thursday 23 Nov
On Sunday 26 November 2006 6:46 pm, Alan Stern wrote:
> On Sun, 26 Nov 2006, David Brownell wrote:
>
> > On Thursday 23 November 2006 6:19 am, Oliver Neukum wrote:
> > > Hi,
> > >
> > > gl620a uses a buffer within a struct. This can corrupt memory on mac
On Thursday 23 November 2006 6:19 am, Oliver Neukum wrote:
> Hi,
>
> gl620a uses a buffer within a struct. This can corrupt memory on machines
> that are not cache coherent.
How could it possibly corrupt memory?
> Regards
> Oliver
>
> Signed-off-by: Oliver Neukum <[EMAIL P
On Sunday 26 November 2006 5:28 am, Nikita V. Youshchenko wrote:
> When AX88xxx hardware packs several incoming frames, it puts second and
> subsequent frames with 2-byte alignment. This may cause situations when IP
> layer gets IP packet not aligned at 32-bit word boundary, which in turn
> may
On Monday 20 November 2006 6:46 pm, Grahame Jordan wrote:
> Hi,
>
> I am using a PXA255 with the g_ether module which uses CDC subset
> Which subset of CDC Ethernet are we implementing here?
The one that excludes all the control operations, including only the
scheme for encapsulating Ethernet fra
On Saturday 18 November 2006 10:10 am, Gregg Levine wrote:
> Hello!
> I am currently planning a project around the Cypress family of 8051
> based USB controllers. Typically these devices need to have firmware
> sent to them before the user can make use of them.
>
> This computer is running 2.4.32
hardware needs re-initialization before it could
be used "normally" again (e.g. unplug/replug, rmmod/modprobe).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/host/ehci-hub.c
===
--- g26.orig/drive
On Thursday 16 November 2006 7:16 am, Alan Stern wrote:
> The net2280 driver is too eager to send zero-length packets when
> IN tokens are received on ep0. No such packet should be sent (the
> driver should NAK) before the gadget driver has queued the proper
> response. Otherwise deferred respons
some were with Intel ones.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/host/ehci-hcd.c
===
--- g26.orig/drivers/usb/host/ehci-hcd.c2006-11-12 12:22:30.0
-0800
+++ g26/drivers/usb/ho
On Wednesday 15 November 2006 12:56 pm, subhash peddamallu wrote:
> Sorry for re-posting, there seems some problem delivering this mail!!
I've received four copies; all but one have HTML. I'm going to
ignore the ones with HTML...
What makes you think there's a delivery problem? I suspect you're
On Monday 13 November 2006 1:08 pm, Laurent Pinchart wrote:
> Hi everybody,
>
> I'm investigating a hardware issue with a high-speed USB webcam. I would like
> to hack the EHCI driver to send no more than a single transaction per frame.
>
> If I understand the big picture clearly, request are sp
On Tuesday 14 November 2006 1:42 pm, Alan Stern wrote:
> On Tue, 14 Nov 2006, David Brownell wrote:
>
> > On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> > > On Mon, 13 Nov 2006, David Brownell wrote:
> > >
> > > > It's a *driver model*
On Tuesday 14 November 2006 12:43 am, Viehweger Thomas wrote:
> > Is this with 2.6.19-rc5, or some older kernel?
>
> The kernel itself is 2.6.12.1, at91_udc and file_storage (as example) are
> patched from 2.6.18.
> I have some trouble to port the BSP to a newer kernel.
> But what can cause the de
On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> On Mon, 13 Nov 2006, David Brownell wrote:
>
> > It's a *driver model* API, which is also accessible from sysfs ... to
> > support
> > per-device policies, for example the (a) workaround. The mechanism exists
&
On Tuesday 14 November 2006 12:48 pm, Andrey Borzenkov wrote:
> On Monday 13 November 2006 22:58, Alan Stern wrote:
> > Andrey:
> >
> > Try this patch for 2.6.19-rc5. Although it doesn't make all the changes
> > Dave and I have discussed, it ought to fix your problem.
> >
>
> It did. Thank you
T
On Monday 13 November 2006 2:33 am, David Cano García wrote:
> Hello everyone,
> I need help with USB host port 3 for PXA270.
> I have the kernel 2.6.9 on a board that had PXA270 and external USB
> transceiver (ISP1104) for
> the USB host port 3.
> I have altered the archive drivers/usb/host/ohci-p
On Monday 13 November 2006 7:57 am, Alan Stern wrote:
> On Sun, 12 Nov 2006, David Brownell wrote:
>
> > > Or are you trying to say that the original device_may_wakeup() value
> > > would
> > > be 0 if the bug were detected?
> >
> > The latter: d
On Sunday 12 November 2006 4:51 pm, Jang Ik-Joon wrote:
> I'm working on making HCD driver for USB 2.O Host controller.
> And I want to make EHCI HCD driver without OHCI HCD.
> It was OK to build kernel with this configurations.
>
> Is it possible to attach USB 2.0 device on that kernel?
Of cours
Minor cleanup/clarification in the ethernet gadget driver, using standard
calls to test for Ethernet multicast and broadcast addresses.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/gadget/e
> > That's why the original OHCI autosuspend code initialized the "can this
> > root hub autosuspend" by testing the root hub wakeup flag:
> >
> > can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> >
> > and then cleared it if any enabled port wasn't suspended, any schedule
> >
> > > > echo -n disabled >
> > > > /sys/devices/pci:00/:00:02.0/usb1/power/wakeup
> > >
> > > That's what I meant ... thanks, and sorry for the confusion.
> >
> > this does not work anymore in current rc5. After writing
> > cat /sys/devices/pci:00/:00:02.0/usb1/power/wakeu
>
> void dev_kfree_skb_any(struct sk_buff *skb)
> {
> if (in_irq() || irqs_disabled())
> dev_kfree_skb_irq(skb);
> else
> dev_kfree_skb(skb);
> }
>
>
> And the first thing dev_kfree_skb_irq() does is to dereference skb...
Yet dev_kfree_skb() -->
On Saturday 11 November 2006 8:06 am, Adrian Bunk wrote:
> The Coverity checker spotted the following NULL dereference of "skb" in
> drivers/usb/gadget/ether.c:
I don't see such a dereference. As usual, free(NULL) is legit.
Is this another case of bogus reports from Coverity? I still need to
r
On Friday 10 November 2006 5:13 am, Vitaly Wool wrote:
> Hello folks,
> the patch inlined below makes the driver's name less generic to avoid
> possible confusion in future, as was requested by Russell King.
Actually, a better name would match the module: "ohci-hcd". And I
see no particular reas
Is this with 2.6.19-rc5, or some older kernel?
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Ap
On Thursday 09 November 2006 12:15 pm, matthieu castet wrote:
> > Feel free to
> > submit a patch to recognize that new chip type.
>
> Well mine is integrated in another controller and is maybe customised.
Then maybe you'd want to add a more general notion than "chip type",
like "map of inter
On Thursday 09 November 2006 11:56 pm, Stefan Meyer wrote:
> Changing it to 0x001C creates a 512MByte windows (this was of course a
> non-generic quick fix).
> Running with anything up to 256MByte is fine.
> My system has 512MByte and it took quite a bit of chasing to find this
> issue.
A bet
On Thursday 09 November 2006 10:07 pm, Andrew Morton wrote:
> > @@ -191,7 +191,7 @@
> > platform_data;
> > /* Enable PHY interface in the control reg. */
> > out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x0004);
> > - out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x001b);
> > + out_
On Thursday 09 November 2006 10:06 pm, Smriti Dhankar wrote:
> This error is first indicated in the case where the host transmits an
> IN token and waits for the DATA0/1 from the device.
Clearly it's a bug in the device ... it didn't respond to the IN token.
Some mass storage devices seem to cr
EXPERIMENTAL ehci patch giving an "ignore_oc=y" module option.
Certain boards seem to like to issue false overcurrent notifications, for
example on ports that don't have anything connected to them. This looks
like a hardware error, at the level of noise to those ports' overcurrent
input signals.
Right. Although these macros are only used in a debug message,
so this isn't something to rush into 2.6.19 ...
- Dave
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pr
> > It certainly gets used, and ISTR every patch submitted in the past
> > several years has been merged ...
>
> So maybe the project should make some news, to say it is still alive.
> Also usb guru/maintainer should advice to use it when they review new
> ez-usb driver.
You're quick to sign up
> > Exactly what's described in the 'Downloading Firmware with "fxload"'
> > seection of the webpage referenced above. No new kernel code needed;
> > it works out-of-the-box on some Linux distros, others may need grab
> > the fxload package.
>
> Yes, but why use a custom userspace mechanism (fxloa
> I don't know what fxload does exactly,
You can then read its manpage ... :)
Or see the section on the topic at
http://linux-hotplug.sourceforge.net/?selected=usb
which gives complete examples of:
> but couldn't there be a simple
> usb driver that takes care of fxloading: it w
> > Use fxload. Keeping your driver as simple as possible is a good reason.
>
> May be, but fxload doesn't seem really maintained/used anymore.
It certainly gets used, and ISTR every patch submitted in the past
several years has been merged ...
--
On Monday 06 November 2006 12:29 pm, Benjamin Herrenschmidt wrote:
> > But you'd make Andrew Morton a bit happier if you were switching
> >
> > readl (...)
> > to
> > ehci_readl(ehci, ...)
> >
> > That is, remove whitespace-for-readability in the "new" code.
>
> Hrm... you want me to re
On Saturday 04 November 2006 10:42 pm, Benjamin Herrenschmidt wrote:
> The issue is that those have an EHCI/OHCI pair which has big endian
> registers but little manipulates DMA data structures in little endian
> form (some would say they are only half broken :-)
I don't actually understand why c
On Saturday 04 November 2006 1:23 pm, Till Harbaum wrote:
> Hi,
>
> Am Samstag, 4. November 2006 21:38 schrieb David Brownell:
> > If you've designed it so that the unrestricted requests can change
> > device state, that's the design problem. Classic examples incl
On Saturday 04 November 2006 10:24 am, Till Harbaum wrote:
> Hi,
>
> Am Samstag, 4. November 2006 18:51 schrieb David Brownell:
> > On Saturday 04 November 2006 9:04 am, Alan Stern wrote:
> > > [libusb can send control messages with appropriate USB_RECIP_* values]
> &
> > The tradeoff was between two approaches, one of which
> > involved much more testing effort than the other. What's
> > been removed here is the code forcing use of the simpler
> > "more readily and completely tested" mode.
>
> Yes, I guess I did misunderstand your comment. But you do agree
On Saturday 04 November 2006 3:24 am, David Lee wrote:
>
> I am looking for USB device controllers that are ACM compliant. Please
> can you advise if you know any of them.
Pretty much any programmable peripheral controller can be made to
talk CDC ACM. If you're after one that does ACM in hardwar
On Saturday 04 November 2006 9:04 am, Alan Stern wrote:
> [libusb can send control messages with appropriate USB_RECIP_* values]
>
> There is no way to prevent libusb from being used to send these kinds of
> messages. If they interfere with the proper operation of the device,
> that's an indica
On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
> It seems to lack the "select MII" at the USB_RTL8150 option that was in
> Randy's first patch?
I was just addressing the usbnet issues ... that driver doesn't
use the usbnet framework.
- Dave
---
NET=y and USBNET_MII=n); I think
I've noticed that same problem in other situations too. So the result can
mean kernels being bloated by stuff that's needlessly enabled ... better
than wrongly being disabled, but contributing to bloat.
Signed-off-by: David Brownell <[EMAIL PROTECTED
On Tuesday 31 October 2006 5:23 pm, Adrian Bunk wrote:
> select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n
Thing is, I'm seeing that get morphed inside Kconfig to "select MII" in
some cases ... the "if x != n" gets ignored, MII can't be deselected.
That looks to me like a Kconfig de
>
> This patch (as811) removes some stale testing code from the root-hub
> resume routine in ohci-hcd. It also adds a spin_lock_irq() call that
> inadvertently got left out of an error pathway.
Just to clarify: it's not "stale testing code".
The "testing" comment I made must have been misunde
On Friday 03 November 2006 4:19 am, zil iram wrote:
>
>Is it possible to configure the osk as a high speed usb device? I've
> looked at the files inode.c and omap_udc.c in the kernel and edited them for
> the osk to be a highspeed device but this doesn't do any good. I don't
> suppose there
> > (Andrew, ISTR that a topological sort won't work in this file.)
>
> I did one just then. It worked for allmodconfig, but it was too big so I
> deleted it.
OK. It was a few releases ago, then, that a topsort couldn't work;
Alan's various updates have improved that aspect too.
I always like
On Tuesday 31 October 2006 10:37 pm, Srinivas G. wrote:
>
> Could any one please point a link about the Linux OTG source code?
Google for "linux usb otg" and the top entry is very relevant:
http://www.linux-usb.org/gadget/h2-otg.html
Also, in the linux-omap tree (currently at 2.6.19-rc4) is a
;t work in this file.)
= CUT HERE
Remove complaint from newer GCCs; they don't like forward function
declarations except in top-level contexts.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: h4/drivers/usb/core/hub.c
> > ...
> > depends on MII if MII != n
> >
> > except that Kconfig doesn't comprehend conditionals like that.
>
> You can express this in Kconfig:
> depends MII || MII=n
Except that:
Warning! Found recursive dependency: USB_USBNET USB_NET_AX8817X MII USB_USBNET
I
> > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> > +#define HAVE_MII
> >...
>
> This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage
> (as already described earlier in this thread)?
Well, "alluded to" not described. Fixable by the equivalent of
config USB_USBNET
> What is the story on the VIA EHCI lost-interrupt (IAA) patches? You
> submitted a patch in the middle of September:
>
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=115863181431280&w=2
>
> but it isn't present in 2.6.19-rc3 or in -mm. Did it get reverted for
> some reason?
It caused trou
drivers follow the standard convention
("select MII") given Randy's patch #1 of 2.
- Dave
-
The usbnet infrastructure must not reference MII symbols unless they're
provided in the kernel being built. This extends also to the ethtool
hooks that referen
On Friday 27 October 2006 1:56 am, Hughes, James wrote:
>
> This message (including any attachments) contains confidential
> and/or proprietary information intended only for the addressee.
> Any unauthorized disclosure, copying, distribution or reliance on
> the contents of this information is
On Thursday 26 October 2006 7:37 pm, Alan Stern wrote:
> By the way, in the OHCI root-hub-resume routine there is a comment about
> "force global, not selective, resume", and code to do just that (i.e.,
> every suspended port gets resumed). Is there any reason for this? It
> sure doesn't seem to
On Thursday 26 October 2006 1:52 pm, Alan Stern wrote:
> On Thu, 26 Oct 2006, David Brownell wrote:
>
> > By the way, I didn't see the same behavior with RC3; at least in
> > terms of the disconnect-before-probe() step. Strange.
> >
> > I didn't try the
By the way, I didn't see the same behavior with RC3; at least in
terms of the disconnect-before-probe() step. Strange.
I didn't try the usbfs thing, though I expect that's gone too.
- Dave
-
Using Tomcat but need to do more
On Thursday 26 October 2006 4:10 am, Armen Baloyan wrote:
> >> This syncronization should be done in upper layer than PCD, i.e. in
> >> gadget,
> >
> > That's not necessarily true, but gadget drivers should certainly be _able_
> > to do that synchronization.
>
> So as I understood device clock s
On Thursday 26 October 2006 9:15 am, Alan Stern wrote:
>
> Anyway, do you disagree with the main point of that patch (i.e., that RD
> doesn't need any handling if RHSC is set at the same time)?
I think that's probably correct, yes. I spent enough time scratching
my head to find differences betw
On Thursday 26 October 2006 10:49 am, Luiz Fernando N. Capitulino wrote:
> | Why aren't these endpoint info functions given as inlined functions
> | in usb.h? They all seem to be one-liners, so having them inlined
> | should be a win.
>
> We had a discussion at the time I introduced these funct
On Wednesday 25 October 2006 10:05 pm, Randy.Dunlap wrote:
> >
> > ... MII should still depend on ETHERNET, right?
> > Just not limited to 10/100 Ethernet.
>
> There is no such config symbol. NET_ETHERNET means 10/100 ethernet.
> Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > The other parts are right, this isn't.
> >
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to
On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to CONFIG_MII ... since it's completely legit to
> > use
> @@ -94,6 +95,7 @@ config USB_RTL8150
>
> config USB_USBNET
> tristate "Multi-purpose USB Networking Framework"
> + select MII
> ---help---
> This driver supports several kinds of network links over USB,
> with "minidrivers" built around a common network driver c
On Tuesday 24 October 2006 9:04 am, Alan Stern wrote:
> When a suspended OHCI controller sees a port's status change, it sets
> both the Root-Hub-Status-Change and the Resume-Detect bits in the
> Interrupt Status register. Processing both these bits, the driver
> tries to resume the root hub twice
On Tuesday 24 October 2006 9:05 am, Alan Stern wrote:
> This patch (as808) fixes a minor race in ohci-hcd's root-hub code. If
> we have to turn off the Root-Hub-Status-Change bit in the Interrupt
> Status register, better to do it _before_ looking for status changes
Patch looks OK, but the point
On Tuesday 24 October 2006 2:37 am, Toralf Förster wrote:
> drivers/built-in.o: In function `usbnet_set_settings':
> : undefined reference to `mii_ethtool_sset'
> drivers/built-in.o: In function `usbnet_get_settings':
> : undefined reference to `mii_ethtool_gset'
> drivers/built-in.o: In function
On Friday 20 October 2006 12:10 am, Armen Baloyan wrote:
> Hi all,
>
> During my work on ISOC EPs support implementation for USB OTG driver I've
> met some difficulties - as is written in usb 2.0 spec:
>
> 5.12.4.1.2 Synchronous
>
> Synchronous endpoints can have their clock system (their n
On Friday 20 October 2006 8:21 am, Alan Stern wrote:
> On Thu, 19 Oct 2006, David Brownell wrote:
>
> > The can't-work-with-this regression is that this means nothing
> > which needs usbfs can work with OHCI any more. That seems to be
> > a secondary failure though
On Monday 02 October 2006 10:50 pm, [EMAIL PROTECTED] wrote:
>
> > > 4. Now again going a step ahead. I plugged in my PCMCIA
> > > card, then I
> > > connected a USB speaker to the USB port of the card and started
> > > playing a song. Now I suspended the system to disk while
> > > the transf
On Tuesday 17 October 2006 2:21 pm, Dmitry Torokhov wrote:
> > One approach would be to add a function callback pointer to the input
> > device structure for autosuspend requests. The transport layer would then
> > be responsible for handling these callbacks and carrying out the suspend.
>
> But
On Sunday 15 October 2006 8:54 pm, Dmitry Torokhov wrote:
>
> > For what it's worth it sort of works now, however testing with an
> > MS Intellimouse Explorer I found that I really needed to use a button
> > to wake it up.
>
> I am afraid that this is a showstopper... While it is accepted that b
On Monday 16 October 2006 8:04 am, Alan Stern wrote:
> > > > Do you have mice that do not require button push to wake up?
> > >
> > > It doesn't matter. The mouse descriptors don't specify whether motion is
> > > a wakeup event, so we have to assume that any mouse will send a wakeup
> > > requ
Just a quick note about problems I observed with RC2 ... I don't have
time to track it down just yet unfortunately, so what we have here is
just some bug reporting.
0 Connect an FT232B based device to root hub, it's handed to OHCI.
(The problem has nothing to do with that device or its driver.
On Wednesday 18 October 2006 12:48 am, Jayaprakash Shanmugam wrote:
> Hello All,
>
> I am using Philips ISP 1561 PCI - USB with PQ2FADS based board. I
> have a couple of USB devices connected to it. Both of them are
> working in high speed. In one of the devices, every 10ms bulk read
> reques
On Thursday 12 October 2006 10:54 pm, Kaburlasos, Nikos wrote:
> Does anyone know whether the linux USB drivers support the suspend
> feature on idle USB ports (i.e. the port has been idle for sometime and
> so the driver transitions it in to a low-power 'suspend' state) while
> the system is activ
> > > Queue B is the flow of URBs from the driver to ehci-hcd. If this
> > > queue drains then the bandwidth is deallocated, something you
> > > desperately want to avoid. It's up to the higher-level driver to
> > > keep the queue non-empty, even if that means submitting URBs with
> > >
On Tuesday 10 October 2006 9:35 pm, Rupesh Kumar wrote:
> > This is the first time I've heard of that kind of hardware bug.
> >
> > If it's always doing 8 transfers, despite being told to do only
> > one, that's pretty significant ...
> >
> > Have you verified with the silicon vendor that this is w
On Thursday 12 October 2006 6:16 am, zil iram wrote:
> I am using OSK and gadgetfs as usb gadget driver. I have
> successfully tested enumeration, reading, writing in Linux using usb.c as
> base code. However, I am having trouble with returning the DeviceId of the
> device.
As Alan ask
Whitespace fixups for drivers/usb/serial/ftdi_sio.c ...
removing end-of-line whitespace, and space-before-tab.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/serial/ftdi_sio.c
===
--- g26.orig/drive
On Friday 13 October 2006 12:31 pm, Open Source wrote:
>
> It seems like the unlinking of completed URBs
> happens asynchronously on a timer. This is a
> surprise to me since I thought this was happening
> on an IRQ from the host controller. But if what I'm
> surmising is correct it would explai
On Wednesday 11 October 2006 10:41 pm, Livio Tenze wrote:
>I use the montavista
> linux kernel 2.4.20 and I read some sources included in this
> distribution, but it is not clear how I have to write the device driver.
I'm fairly sure I've seen mentino of an imx UDC driver for recen
On Tuesday 10 October 2006 12:26 pm, Alan Stern wrote:
>
> You're talking about detecting URB completion before a completion IRQ
> arrives. In other words, polling. I would prefer not to see that added
> to the HCDs, but it is a possibility.
Actually EHCI can and does run into a similar case,
On Tuesday 10 October 2006 1:20 pm, Pete Zaitcev wrote:
> On Tue, 10 Oct 2006 16:02:54 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
> > On Tue, 10 Oct 2006, Christopher "Monty" Montgomery wrote:
>
> > > Ah, EHCI (or USB in general) specifies a completion interrupt happens
> > > only at th
On Tuesday 10 October 2006 1:07 am, Rupesh Kumar wrote:
> According to the OHCI Specification there is chance for 8 PSWs but in
> the driver we are using only 2 PSW.but my hardware is always doing
> 8PSW DMA Transfer there by hardware is overwriting the Software fields
> sitting immediately after t
On Monday 09 October 2006 7:46 pm, Alan Stern wrote:
> On Mon, 9 Oct 2006, David Brownell wrote:
>
> > > > > I don't like the idea of having two separate pathways for reporting
> > > > > the
> > > > > same kind of error. If on
On Monday 09 October 2006 10:10 am, Christopher "Monty" Montgomery wrote:
> >
> > You have not ** YET ** tried to do it the way that's known to work,
> > so it's no surprise you've been seeing the failures which lead to
> > the requirement to use double buffering.
>
> Uh... I've been trying to use
On Saturday 07 October 2006 12:47 pm, Alan Stern wrote:
> On Sat, 7 Oct 2006, Christopher "Monty" Montgomery wrote:
>
> > Let's establish how to report missed slots, I'll update the patches,
> > and then try to figure out what's going on with usbaudio.
>
> Okay, let's move on to discuss this. Pa
On Monday 09 October 2006 9:44 am, [EMAIL PROTECTED] wrote:
> On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Monday 09 October 2006 9:11 am, [EMAIL PROTECTED] wrote:
> > > FWIW, if we really could get 5ms latency with a 4ms buffering
> > > requirement
On Monday 09 October 2006 9:43 am, Christopher "Monty" Montgomery wrote:
> On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Monday 09 October 2006 9:02 am, Christopher "Monty" Montgomery wrote:
> > > On 10/9/06, David Brownell <[EMAIL P
On Monday 09 October 2006 9:37 am, Christopher "Monty" Montgomery wrote:
>
> I hand you a pointer to memory and ask you what type it is. You can't
> tell me.
A C "struct foo *" points to a "foo".
For a C "void *", the type info is out-of-band.
Now, the notion of hardware "typed pointers" has b
On Monday 09 October 2006 9:02 am, Christopher "Monty" Montgomery wrote:
> On 10/9/06, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Exactly why I'm reminding you that your driver -- queueing only one
> > URB at a time -- is the source of a **LOT** of
On Monday 09 October 2006 9:11 am, [EMAIL PROTECTED] wrote:
> FWIW, if we really could get 5ms latency with a 4ms buffering
> requirement, that counts as 'good enough for now' and probably 'good
> enough for the forseeable future'.
5 ms latency and 4 ms buffering means 1 ms dropout, yes?
If you w
On Monday 09 October 2006 4:44 am, Daniel Stenberg wrote:
> The problem I have is that when I insert my USB cable from my usb-storage
> device into my Linux board, I get a few USB IRQs fine and the USB layer
> detects the presence of a new device and all and sets it up like:
>
> usb 1-1: new hig
On Friday 06 October 2006 7:00 pm, Christopher "Monty" Montgomery wrote:
> On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Nope; not a tradeoff. For one thing, the pointers _are_ typed;
> > for another, we have no option to trade _to_ since the hardw
601 - 700 of 5700 matches
Mail list logo
