On Sat, Mar 16, 2013 at 10:34:43PM +0200, Anonymous wrote:
> On 16/03/2013 10:15 PM, Greg KH wrote:
> >Look at the data on the wire, and notice all of the delay and gaps that
> >could have been filled with real data, but the protocol involved here
> >(the "old" usb storage spec) prevents the full u
On 16/03/2013 10:15 PM, Greg KH wrote:
Look at the data on the wire, and notice all of the delay and gaps that
could have been filled with real data, but the protocol involved here
(the "old" usb storage spec) prevents the full use of the xhci
controller.
Now if you actually were able to keep th
On Sat, Mar 16, 2013 at 10:00:38PM +0200, Anonymous wrote:
> On 16/03/2013 09:44 PM, Greg KH wrote:
> >I'm guessing here that you aren't talking about Linux.
>
> My question is not related to Linux. It's related to xhci, and I
> asked on this mailing list because it's a public list with people
> e
On 16/03/2013 09:44 PM, Greg KH wrote:
I'm guessing here that you aren't talking about Linux.
My question is not related to Linux. It's related to xhci, and I asked
on this mailing list because it's a public list with people experienced
in xhci.
The question is: what possible scenario could
On Sat, Mar 16, 2013 at 09:11:34PM +0200, Anonymous wrote:
> I'm writing a kernel driver for xhci.
Why? We already have a Linux xhci driver. Why write another one?
And why ask for questions anonymously? That's a bit strange, don't you
think?
> USB3 is used mainly for high-performance external
I'm writing a kernel driver for xhci. USB3 is used mainly for
high-performance external disk drives.
The driver receives a memory buffer to do DMA from (or to.) Buffer can
come from either user-land or kernel-land. So driver can't be sure the
buffer is mapped into kernel virtual address-space
Ok. I use 2 em2840-based usb sticks (em28xx driver) attached to a
Marvell Kirkwood-SoC with a orion-ehci usb controller. These usb sticks
stream dvb data (digital TV) employing isochronous usb transfers (user
application is vdr).
Starting from linux-3.6 I see
ERROR: 1024 KiB atomic DMA cohere
On Sat, 16 Mar 2013, Jenya Y wrote:
> Alan, looks like we are not quite there yet, just tried a fresh 3.8.3
> build with both of your patches and here is what I have -
>
> [7.797975] usb 1-2.2: can't set config #1, error -19
> [7.798332] usb 1-2.2: USB disconnect, device number 3
> [7
On Fri, 2013-03-15 at 08:02 +0100, Bjørn Mork wrote:
> Ben Hutchings writes:
>
> > On Thu, 2013-03-14 at 12:05 +0100, Bjørn Mork wrote:
> >> commit bd329e1 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
> >> introduced a new policy, preferring MBIM for dual NCM/MBIM functions if
> >
On Sat, 16 Mar 2013, Soeren Moch wrote:
> I implemented the counter. The max value is sampled at the beginning of
> end_free_itds(), the current counter value is sampled at the end of this
> function. Counter values w/o a max number are from the error path in
> itd_urb_transaction().
> The numb
On Friday, March 15, 2013 12:53 AM, Oliver Neukum wrote:
> The problem is that I needed to work around the counting nature of
> completions.
> If you go to a waitqueue the need is removed. Your original patch together
> with
> the change to use a wait queue would be correct.
Got that. Below is
Okay. We don't need to see all those -19 errors. The patch below
(applied on top of the previous patch) will eliminate them.
I think I should mention that one thing has chnaged in my installation. I've
updated my systemd to 198, but it had no negative effects on 3.9
Let me know if I should
12 matches
Mail list logo
