On Saturday 07 October 2006 11:40 pm, Oliver Neukum wrote:
> Am Sonntag, 8. Oktober 2006 02:03 schrieben Sie:
> > On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> >
> > > > > I dare say that the commonest scenario involving USB is a laptop with
> > > > > an input device attached. Input
> > But the root cause is still that streaming ISO with just one URB is
> > not a viable approach ... the driver on top of usbcore was doing the
> > wrong thing.
>
> I understand now that's the fundamental Linux design, but only Linux
> seems to implement it this way. MacOSX can do 2ms sample/pla
On Monday 09 October 2006 7:43 am, Christopher "Monty" Montgomery wrote:
>
> As for the using a single URB being an abuse of ISO: is this an abuse
> of ISO or an abuse of the way Linux does ISO?
The former ... even if you had a realtime OS running as part of a
system which managed latencies well
On Sunday 08 October 2006 4:51 pm, [EMAIL PROTECTED] wrote:
>
> When sample and playback are lockstep (read 64 samples, process, write
> them for playback, read next 64 samples, process, write them for
> playback), we will only ever be one URB deep.
Can't be guaranteeed. Never use less than two
On Sunday 08 October 2006 4:37 pm, Christopher "Monty" Montgomery wrote:
> > > For example, let's say an URB is submitted for slot S, just as S's
> > > microframe is starting. ehci-hcd adds the URB into the hardware schedule;
> > > was it in time for the controller to see it?
>
> Right now, that
[ $SUBJECT still needs correction in many replies ... ]
On Sunday 08 October 2006 8:21 pm, Alan Stern wrote:
> On Sun, 8 Oct 2006, Christopher "Monty" Montgomery wrote:
>
> > > I don't like the idea of having two separate pathways for reporting the
> > > same kind of error. If one reporting tech
On Monday 09 October 2006 7:18 am, Christopher "Monty" Montgomery wrote:
>since most of the submissions
> will be happening inside the interrupt handler and thus will be
> running un-preemptible (am I correct here?).
IRQ handlers can be preempted "for real" in some realtime kernels,
where
On Sunday 08 October 2006 1:03 am, Vitaly Wool wrote:
> On 10/7/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > It's still missing bus suspend and resume methods in ohci_pnx8550_hc_driver
> > ...
>
> Yea, those are in NOTYET state. Is this a stopper though? I
On Sunday 08 October 2006 8:16 pm, Alan Stern wrote:
> On Sun, 8 Oct 2006, Christopher "Monty" Montgomery wrote:
>
> > > I don't know what this "low-latency" thing is you're referring to. But
> > > it sounds like it's trying to be _too_ low.
> >
> > Professional audio applications generally spec
On Sunday 08 October 2006 4:29 pm, Christopher "Monty" Montgomery wrote:
> Oh, Hell. I think I know why. Because low-latency is only ever one
> URB deep. There's no second URB waiting when the first completes. So
> the stream is shut down.
That's a bug in the driver; it's misusing ISO. Unles
On Saturday 07 October 2006 10:16 am, Oliver Neukum wrote:
> > > I dare say that the commonest scenario involving USB is a laptop with
> > > an input device attached. Input devices are for practical purposes always
> > > opened. A simple resume upon open and suspend upon close is useless.
That is
> > EHCI can't really do "square tetris". It's not a video game. ;)
>
> Very funny :-)
:)
And also, the parts are not uniform. ITDs are uniform; SITDs are not,
especially in conjunction with FSTNs.
> What I meant was that the USB docs make it very clear (in examples and
> whitepapers, less
On Saturday 07 October 2006 11:49 am, Alan Stern wrote:
> On Fri, 6 Oct 2006, Christopher "Monty" Montgomery wrote:
>
> > On 10/6/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > >
> > > I don't know the details of ehci-hcd, but this may well be unfeasible. It
> > > would require checking the status
On Saturday 07 October 2006 11:58 am, Arnd Bergmann wrote:
> On Thursday 28 September 2006 03:28, David Brownell wrote:
> > On Saturday 16 September 2006 4:02 pm, Arnd Bergmann wrote:
> > > This driver adds support for the DeLOCK USB ethernet adapter
> > > and pote
It's still missing bus suspend and resume methods in ohci_pnx8550_hc_driver ...
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT
On Friday 06 October 2006 9:38 pm, Christopher "Monty" Montgomery wrote:
> You say 'fell behind', I say 'xrun'... Did I come away with the wrong
> interpretation?
When you said that we had previously reached the conclusion that there
was no bug there, I disagreed ... we hadn't discussed that poin
On Friday 06 October 2006 9:59 pm, Greg KH wrote:
>
> I didn't understand what was so objectionable with the alsa driver
> change in the first place, but oh well, I'll wait for the next
> iteration...
One thing is that nothing actually prevented the resubmit from
getting the same fault code ... s
On Friday 06 October 2006 9:57 pm, Christopher "Monty" Montgomery wrote:
> On 10/7/06, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > I'd made suggestions there ... probably the simplest way for things like
> > the audio driver is to return a positive stat
> > >You seem to have missed a key point of splitting a monster patch
> > >into a sequence of independent patches ... the independence!
> >
> > I would assert the key point is being able to see each change in
> > isolation clearly.
>
> I concur.
That's one aspect of independence. Also, "git bis
On Friday 06 October 2006 9:18 pm, Christopher "Monty" Montgomery wrote:
> On 10/7/06, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > Ok, then what is the proper channel for reporting the missed slots? Did
> > I miss something here?
>
> I think Alan is mostly done p0wning me, but we've not decided wha
On Friday 06 October 2006 9:15 pm, Christopher "Monty" Montgomery wrote:
> On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > Not a good analogy. More accurate would be a jigsaw puzzle ... because
> > you can pull a piece out of the middle, and then safely pu
On Friday 06 October 2006 8:51 pm, Christopher "Monty" Montgomery wrote:
> On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Friday 06 October 2006 7:22 pm, Christopher "Monty" Montgomery wrote:
>
> > > Except that your comment is incorre
On Friday 06 October 2006 8:05 pm, Alan Stern wrote:
> On Fri, 6 Oct 2006, Christopher "Monty" Montgomery wrote:
> > In any case, setting a status flag on the next completion is not good
> > enough; that tells you an xrun happend a long time ago. Notification
> > has to happen upon next submissio
NOTE: I updated $SUBJECT to be accurate.
On Friday 06 October 2006 7:56 pm, Christopher "Monty" Montgomery wrote:
> On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > Hmm, in the current EHCI scheduler, the place which returns EL2NSYNC is
> > argu
On Friday 06 October 2006 8:18 pm, Alan Stern wrote:
> On Fri, 6 Oct 2006, Christopher "Monty" Montgomery wrote:
>
> > Something, somewhere, causes the reservation to be lost.
>
> Basically you're saying that the old driver would sometimes lose a
> bandwidth reservation. I'm not disputing that.
On Friday 06 October 2006 7:47 pm, Christopher "Monty" Montgomery wrote:
> On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Thursday 05 October 2006 12:21 pm, Christopher "Monty" Montgomery wrote:
> > > endpoint_disable is where the budget is
On Friday 06 October 2006 7:22 pm, Christopher "Monty" Montgomery wrote:
> > ... you're not including whitespace which you _should_ include,
> > and (elsewhere) are adding whitespace you should not include.
>
> I accept this in the context of the kernel coding style. Given that
> this is all enti
On Friday 06 October 2006 6:25 pm, Christopher "Monty" Montgomery wrote:
> On 10/6/06, Christopher Monty Montgomery <[EMAIL PROTECTED]> wrote:
> > Justify that.
>
> Ah, the list is delivering things in a weird order, you've addressed
> this point in mail that just arrived.
>
> My other points sti
On Thursday 28 September 2006 8:05 am, Christopher "Monty" Montgomery wrote:
> On 9/27/06, David Brownell <[EMAIL PROTECTED]> wrote:
> > > B) Break struct ehci_qh into two parts, one allcated with
> > >dma_pool_alloc() and one allocated with kmalloc(), wher
On Thursday 28 September 2006 4:50 am, Marcus Comstedt wrote:
>
> David Brownell <[EMAIL PROTECTED]> writes:
>
> > The use of kref was a simplification ... adopting an idiom that was
> > used in many other places in the kernel. You're right that there
> &g
On Thursday 28 September 2006 12:33 am, Christopher "Monty" Montgomery wrote:
> patch 15: This is a usbaudio fixed necessitated by fixing the isoch
> underrun detection/reporting in ehci. usbaudio playback nominally
> causes one harmless underrun in setup that the usbaudio code doesn't
> currently
On Friday 06 October 2006 11:48 am, Christopher "Monty" Montgomery wrote:
> > You still don't seem to understand. Kernel latency by itself _cannot_
> > cause a bandwidth reservation to be lost.
>
> I call bullshit. A single well-placed printk inside the spinlock is
> enough latency to cause al
Technical content of this one seems fine, but there are lots of
Documentation/CodingStyle issues level to resolve.
> patch 1: This patch slightly refactors isoch stream cleanup such that
> stream state is more persistent; it is instantiated at first transfer
> and not released until endpoint shutd
On Friday 06 October 2006 12:12 am, Vitaly Wool wrote:
> + /*
> + * root hub support
> + */
> + .hub_status_data = ohci_hub_status_data,
> + .hub_control = ohci_hub_control,
> +#ifdef CONFIG_USB_SUSPEND
> + .hub_suspend = ohci_hub_suspend,
> +
On Tuesday 26 September 2006 10:00 pm, Christopher "Monty" Montgomery wrote:
> --- a/sound/usb/usbaudio.c2006-09-26 22:10:24.0 -0400
> +++ b/sound/usb/usbaudio.c2006-09-26 22:35:43.0 -0400
> @@ -838,6 +838,9 @@ static int start_urbs(struct snd_usb_sub
> subs->running =
On Friday 06 October 2006 12:04 am, Oliver Neukum wrote:
> Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> >
> > > - the issues of manual & automatic suspend and remote wakeup are
> > >
On Thursday 05 October 2006 12:21 pm, Christopher "Monty" Montgomery wrote:
> > I don't know the details of how ehci-hcd used to implement this. But
> > waiting until endpoint_disable is wrong.
>
> endpoint_disable is where the budget is released, which has
> little/nothing to do with the hardwa
On Wednesday 04 October 2006 6:07 am, Clemens Ladisch wrote:
>
> Is it possible to tell the scheduler that the iso stream has stopped/
> restarted, without calling usb_set_interface()?
Yes, just let the urb queue drain. I could imagine some of the sound
drivers aren't monitoring the queue close
This is a more correct fix for the way the ohci hcd was referencing
pt_regs in the unlink paths.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- linux-2.6.orig/drivers/usb/host/ohci-q.c2006-10-05 20:04:49.0
-0700
+++ linux-2.6/drivers/usb/host/ohci-q.c 2006-10-05
On Tuesday 03 October 2006 2:14 pm, Jonathan McDowell wrote:
> Am I correct in thinking there is no current SA11x0 USB gadget driver
> for 2.6? I've found various mentions of one and the
> CONFIG_USB_GADGET_SA1100 define is still referenced in 2.6.18, but don't
> seem to be able to find any actual
On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> - the issues of manual & automatic suspend and remote wakeup are orthogonal
> - there should be a common API for all devices
AFAIK there is no demonstrated need for an API to suspend
individual devices. Of course there's the question of
On Tuesday 26 September 2006 7:57 am, Dmitry Antipov wrote:
> Hello,
>
> I'm working with PXA27x hardware and going to check USB ethernet gadget
> (RNDIS mode)
> with 2.6.18 on PC host. After a short investigation, I was stucked because:
Yes, there are bugs there ... I thought they'd been fixed,
> > No such file in current kernel.org git ... ???
>
> Oh I'm confused as well... Though I did diff against linux-mips git
> tree I could hardly imagine that a USB driver might be in MIPS tree
> but not in mainline...
Happens all the time with platform trees. Someone has to push such
drivers to
On Tuesday 03 October 2006 4:31 am, Vitaly Wool wrote:
> Hello folks,
>
> inlined is the patch that fixes the breakage for PNX8550 USB OHCI driver.
>
> drivers/usb/host/ohci-pnx8550.c | 41
> +---
> 1 file changed, 10 insertions(+), 31 deletions(-)
No such
On Thursday 05 October 2006 2:33 am, Vitaly Wool wrote:
> Hello Greg,
>
> the small patch inlined fixes the compilation breakage for the pnx4008 USB
> OHCI driver.
>
> drivers/usb/host/ohci-pnx4008.c |2 --
> 1 file changed, 2 deletions(-)
There's a similar patch already in Greg's patchset
On Tuesday 03 October 2006 11:04 am, Alan Stern wrote:
> On Mon, 2 Oct 2006, David Brownell wrote:
>
> >
> > > In principle it's possible to change ehci-hcd so that the SETUP
> > > transaction of a control transfer is sent in a different microframe from
>
On Tuesday 03 October 2006 6:10 am, Rumjantsev Egor wrote:
> Is it possible to allocate large buffers for bulk transfer with
> vmalloc_32 function?
Read the first section of Documentation/DMA-mapping.txt where
it describes what memory is DMA-able. All buffers you pass to
the USB subsystem (bulk
> > You probably won't get too far trying to understand Windows' behavior by
> > asking questions on a Linux mailing list. :-)
>
> Well, many talented Linux programmers know more about Windows than Windows
> programmers themselves :-)
And assuming that were true, I think they'd still not want
> In principle it's possible to change ehci-hcd so that the SETUP
> transaction of a control transfer is sent in a different microframe from
> the following IN/OUT transactions. In practice it might be a painfully
> difficult change to write.
Probably just mark only one TD active at a time, and
So to oversimplify, this controller builds on a non-PCI implementation
of EHCI, by reusing much of the core silicon design ... including most
usefully DMA queues which actually (on first glance) make sense. This
might be the first peripheral controller I've seen with a sensible DMA
interface, faci
On Friday 29 September 2006 3:34 pm, Greg KH wrote:
> On Wed, Sep 27, 2006 at 02:21:04PM +0800, Li Yang wrote:
> > Freescale high-speed USB SOC can be found on MPC834x and
> > probably more in the future. Its DR(dual-role) module
> > can work as a USB device. This patch adds its support
> > for L
> > OK. It seems we are looking at different versions. In my tree that
> > file has 208 lines.
>
> You should be using the gregkh-all development kernel:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
or current GIT from kernel.org ...
---
removed from usbcore.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: at91/drivers/usb/host/ohci-pnx4008.c
===
--- at91.orig/drivers/usb/host/ohci-pnx4008.c 2006-09-30 19:16:13.0
-0700
+++ at91/drivers/us
On Monday 02 October 2006 3:31 am, Oliver Neukum wrote:
> Hi,
>
> I am working on suspend/resume for usblp. If I write "3" into state
> I am getting back "2". Is that a desireable behavior? Shouldn't we
> fail if we cannot do exactly what is required?
This is one of many reasons the /sys/devices/
On Thursday 28 September 2006 5:20 pm, Andrew Morton wrote:
> On Thu, 28 Sep 2006 17:08:33 -0700
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > ... reviewing and testing those new OHCI changes is still on my
> > list;
>
> erm, we prefer to do that before c
> --- a/drivers/usb/host/ohci-hub.c~ohci-add-auto-stop-support-hack-hack
> +++ a/drivers/usb/host/ohci-hub.c
> @@ -132,6 +132,10 @@ static inline struct ed *find_head (stru
> return ed;
> }
>
> +#ifdef CONFIG_PM
> +static int ohci_restart(struct ohci_hcd *ohci);
> +#endif
> +
> /* caller
rrupt. The problem goes away when
> I'm using an active USB hub, so I assume it's not related to
> the device driver, but rather to the hardware.
>
> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
... yes, I'
On Wednesday 27 September 2006 3:06 am, Thomi Aurel RUAG A wrote:
> Hi
> Im working on a Intel XScale PXA-270 Board with linux 2.6.17
> (linux-2.6.17-pcm027-3).
I hope you know that the pxa27x UDC code is still not working
very reliably. Oddly enough, the hardware folk Intel tasked with
designing
On Sunday 24 September 2006 5:18 am, Theodoros V. Kalamatianos wrote:
> I have encountered at least 3 hubs (2 usb2 & 1 usb1) that will consume a
> lot of power (about 2-2.5W if the laptop power consumption readings are to
> be trusted) and heat up a lot (to the point of being too hot to touch fo
On Monday 25 September 2006 1:17 pm, Gerhard Pircher wrote:
> Now, the problem is deciding in which of these steps the actual error
> lies, since none of these facts (apart from #6) is set in stone. In
> my opinion though, it makes sense to simply say that atomic_t:s (and
> therefore kref:s) are
On Wednesday 27 September 2006 5:39 am, Ronnie Hedlund wrote:
>
> I wonder what the directory "drivers/usb_new/" is for, as the "drivers/usb/"
> directory seems to be the one that is used. Both contains partly the same
> files but there are differences.
>
> Kernel: Montavista Preview Linux 2.4
On Wednesday 27 September 2006 1:11 pm, Laurent Pinchart wrote:
> Logitech has been kind enough to investigate the problem. It seems a hardware
> bug is triggered when the control transfer transactions are sent "too fast".
> Preliminary results show that the hardware misses the second transactio
On Wednesday 20 September 2006 7:18 pm, Aras Vaichas wrote:
> David Brownell wrote:
> David Brownell wrote:
> > On Sunday 17 September 2006 9:59 pm, Aras Vaichas wrote:
> >> I'm using an at91rm9200 with Linux 2.6.16. Under some unusual
> >> circumstances, I
>
> > > This really solves my problem. One fundamental problem (at least given
> > > the SAM7 register set) remains: I have no indication to decide which of
> > > the data OUT packets was the last, and when the device should return the
> > > status stage IN packet.
> >
> > The at91_udc driver shou
On Wednesday 20 September 2006 10:09 am, Alan Stern wrote:
> Dave:
>
> I want to modify the bus_suspend and bus_resume routines in ohci-hub.c.
> The idea is to have versions that can operate entirely in interrupt
> context.
>
> Normally of course this would be impossible. But if you know that
On Wednesday 20 September 2006 10:58 am, Harald Welte wrote:
> > When a control-out transfer takes, the host controller sends a SETUP
> > packet followed by as many OUT/DATA packets as necessary to transfer the
> > data, but no zero-length OUT/DATA. There is a zero-length IN packet to
> > termina
On Tuesday 19 September 2006 1:30 pm, Alan Stern wrote:
> None of this is relevant for the vanilla 2.6.18-rc series, since the USB
> autosuspend code isn't in there at all.
Even that one which can apply just fine to the RC series, addressing
that problem which appears only without CONFIG_USB_SUS
> i am using 2.6.11,
Try to use a more current kernel. Likely it won't matter
here, but 2.6.11 is over 18 months old by now ... :)
> and EHCI HCD. during boot up i get
> following message:
>
> "usb 1-0:1.0: over-current change on port 1"
>
> and after the system is up none of the USB device
On Tuesday 19 September 2006 7:14 am, Alan Stern wrote:
> This patch (as787) creates a new workqueue thread to handle delayed
> USB autosuspend requests.
So, unlike the other patch you sent recently this is an MM-only patch,
and not relevent for 2.6.18-rc7 etc?
- Dave
On Sunday 10 September 2006 6:10 pm, Lisa Y. wrote:
> Hi,
>
> I can't seem to figure this out. But each time I run the usb.c program,
> it does not seem to go past the write () part in the
> simple_source_thread. It outputs a "signothing 22" and I'm not sure
> whether anything has been written to
On Sunday 17 September 2006 9:59 pm, Aras Vaichas wrote:
> I'm using an at91rm9200 with Linux 2.6.16. Under some unusual circumstances, I
> can create a failure.
Can you reproduce this with 2.6.18-rc7? That newer driver code may
be usable as a straight backport.
> Here is what I do to create the
On Tuesday 05 September 2006 8:26 am, Alan Stern wrote:
> Lots of people have asked why USB mass-storage devices don't survive
> suspend-to-disk (swsusp). The answer is technical and not too
> interesting;
Not that technical: "Unlike most older busses, USB monitors connection
state during suspe
On Thursday 31 August 2006 4:01 am, Rodolfo Giometti wrote:
> On Thu, Aug 31, 2006 at 03:36:42AM -0700, David Brownell wrote:
> > But in general, userspace should be assuming that all removable
> > media will have been removed by the time the system comes back up,
> > and
On Tuesday 19 September 2006 3:43 am, Jiri Kosina wrote:
> (by the way, EHCI and OHCI seem to have broken (read: missing) locking
> when accessing the hcd->state. Should I fix it by per-hcd spinlock, or
> does the patch already exist somewhere?)
They should only ever access it while holding the
On Friday 15 September 2006 3:45 pm, Pete Zaitcev wrote:
> On Thu, 14 Sep 2006 13:19:53 +0200, "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > In fact I can reproduce it on two different boxes now.
>
> How about the attached?
>
> -- Pete
Sign
On Thursday 14 September 2006 1:21 am, Milan Svoboda wrote:
> From: Milan Svoboda <[EMAIL PROTECTED]>
>
> This patch removes limitation which prevents use of drivers that support
> speeds different than full speed.
This is the right way to fix that issue, thanks.
- Gadget drivers can support e
On Friday 15 September 2006 3:13 pm, Rafael J. Wysocki wrote:
> Hi,
>
> It looks like the ohci_hcd driver sometimes has problems with the
> initialization (eg. USB mouse doesn't work after a fresh boot and reloading
> of the driver helps).
>
> I have observed this on two different x86_64 boxes (H
On Monday 18 September 2006 6:44 pm, Jiri Kosina wrote:
> Hi,
>
> EHCI, UHCI and OHCI USB host drivers are not consistent when returining
> error values from their _suspend() functions, in case that the device is
> not in suspended state. This could confuse users, so let all three of them
> ret
Somewhere along the line, a variable in a USB-OTG codepath
stopped being used; this removes the relevant compiler warning.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: d26.rc4test/drivers/usb/core/hub.c
===
-
chips,
and AFAIK won't affect non-VIA hardware. VIA systems need this code to
recover from silcon bugs whereby the "async advance" IRQ isn't issued.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/host/ehci.h
===
> First of all, at91_udc activates the pullup in ..._register_driver(), so
> even if I don't load any gadget module, the host starts enumeration.
I don't follow. If you (successfully) register a gadget driver
and don't usb_gadget_disconnect() in the gadget driver bind()
method, it's *required* to
> > > Apparently, there's a window when OHCI is shut down, when we shut the
> > > controller down and freed hcca, but did not release the IRQ. On a shared
> > > IRQ, some other device interrupts, and we oops referring to hcca.
> > >
> > > The attached patch looks like a ham-fisted way to fix this .
> Apparently, there's a window when OHCI is shut down, when we shut the
> controller down and freed hcca, but did not release the IRQ. On a shared
> IRQ, some other device interrupts, and we oops referring to hcca.
>
> The attached patch looks like a ham-fisted way to fix this ...
Indeed. Did you
> No, the receive errors are independent from the status interrupt.
> I have now got confirmation by another user that they also
> happen on a different thinkpad when not using a USB hub, but
> with a hub everything seems fine.
Odd. Hardware issues, I guess ... I'd like to understand better
just
This includes two one-liners forwarded to me for the OHCI support on at91:
- KB920x (and other boards with CPUs in non-BGA packages) need a slightly
different way to say "ignore that port, it's not pinned out";
- On resume, if we turn clocks on, record that we did so.
Signe
On Wednesday 09 August 2006 12:55 am, Milan Svoboda wrote:
> > On Tuesday 08 August 2006 2:49 am, Milan Svoboda wrote:
> > > This patch adds resume event into gadgetfs.
> >
> > Actually I recall intentionally omitting this as there'd be
> > no real point to it ... did you have a use case for this
On Sunday 20 August 2006 1:07 pm, Arnd Bergmann wrote:
> This driver adds support for the DeLOCK USB ethernet adapter
> and potentially others based on the MosChip MCS7830 chip.
>
> It is based on the usbnet and asix drivers as well as the
> original device driver provided by MosChip, which in tur
On Sunday 27 August 2006 1:41 pm, Arnd Bergmann wrote:
> The mcs7830 chip always appends a byte with status information
> to an rx frame, so the URB needs to reserve an extra byte.
Shouldn't you add VLAN_HLEN too, in case 802.1q is in use?
I'm not entirely sure how that's expected to work myself.
linelength and whitespace fixes; and minor data segment shrinkage.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/gadget/net2280.c
===
--- g26.orig/drivers/usb/gadget/net2280.c 2006-07-06
I'm unfortunately on the road right now, but I'll see if I can borrow
a wakeup-capable device next week to see what's up. As I've said,
EHCI wakeup has worked fine for me the last many times I've checked ...
- Dave
-
Using
From: "Skip Hansen" <[EMAIL PROTECTED]>
For ep0out transfers (rare), be sure to copy the right data to userspace.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/gadget/inode.c
===
--
> > You're overreacting more than a little bit. We want that, and also
> > want good clean code. It's not as if this patch was submitted to
> > annoy you (or anyone).
>
> Yep, I certainly was. Apology might not have made it to the list yet.
I got it later ... accepted.
> I try
> I'm committed to seeing this patch to either oblivion or production,
> and globally altering whitespace is going to blow my time for *no net
> benefit to anyone*.
Cleanups like these _do_ have benefit.
> If you really are that wholly uninterested in a
> complete scheduler,
You're overre
> > > do better than that; see how ohci-at91.c will keep USB active during
> > > "standby" sleep, that's the best in-tree example today.
> >
> > It disables only the clocks... it seems a "poor" suspend/resume
> > support...
>
> Better than nothing. What else would you like to disable?
More to th
> Date: Thu, 31 Aug 2006 11:24:17 +0200
> From: Rodolfo Giometti <[EMAIL PROTECTED]>
>
> When I put the system to sleep and then it wakes up everything works
> well _if_ the USB key is not mounted before the sleep. For instance,
> if I mount partition "/dev/sda1" (first USB key partition) and then
On Wednesday 30 August 2006 4:36 pm, Christopher Montgomery wrote:
> I'd not normally complain, but
>
> I'll need to do addiitonal work and release an all new patchset of the
> ehci-scheduler... just to deal with cosmetic whitespace changes?
Not until 2.6.18-early, no. At which point it's ro
> Oops, crossed lines. Greg, this patch isn't needed. One that you have
> already applied (as754) takes care of the problem.
What's the name for that one in Greg's tree?
-
Using Tomcat but need to do more? Need to support
[ ... when you have an editor set to remind you of whitespace bugs ... ]
Cosmetic EHCI changes: remove end-of-line whitespace, spaces before tabs.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/host/
ongly enabled IRQs on exit, by using the wrong locking/irq primitives.
This patch switches back to the primitives which save/restore IRQ flags.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/usb/core/hcd.c
For systems using the Mentor HDRC controllers we get better TX DMA throughput
if we can avoid falling back to PIO to write zero length packets ... so tell
the driver to avoid ZLPs.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: d26.rc4test/drivers/usb/gadget/e
701 - 800 of 5700 matches
Mail list logo
