On Friday 29 June 2007, Michael P. Cosby wrote:
> I'm not sure if this is the correct place to followup to this, but a
> quick
>google search didn't give me a related bug database for this issue. This is
> in response to the patch posted in this message:
>
>http://lists.zerezo.com/linux-usb-
I'm not sure if this is the correct place to followup to this, but a
quick
google search didn't give me a related bug database for this issue. This is in
response to the patch posted in this message:
http://lists.zerezo.com/linux-usb-devel/msg20582.html
(the "correct" but much slower link
If you can't persuade ur girl that she deserves only your tiny size,
so, never mind, just try out our wonderful pellet and you'll
show your girlfriend a REAL SIZE!
You can find out how to do it
on our official website: http://www.mynratravel.com/
and it's REALLY CHEAPER!
--
tqqfqjqfpponrromo
Am Samstag, 30. Juni 2007 schrieb David Brownell:
>
> > >
> > > I'm also not sure that what I have in mind is so very different from
> > > what you're trying to do. Basically, instead of asking the HCD how
> > > much space it needs for a certain transfer length & type, simply tell
> > > the H
> >
> > I'm also not sure that what I have in mind is so very different from
> > what you're trying to do. Basically, instead of asking the HCD how
> > much space it needs for a certain transfer length & type, simply tell
> > the HCD to allocate the resources directly. Then you could also ha
> > Gaak. Just pass the usb_host_endpoint pointer in, with the relevant
> > length indicator. Four functions would be ugly, unclean, unneceesary.
> > All the relevant data is in the endpoint descriptor, which is stored
> > in the host_endpoint struct.
>
> This would be true, were it not for tho
Hi Oliver,
> > > Why do you care that much about the size of struct urb? There are a few
> > > hundred of these structures at most at any given time. I think we gain
> > > more
> > > in memory usage if we make using URBs easier, shrinking drivers' code.
> >
> > Firstly, we certainly are reasonin
Am Freitag, 29. Juni 2007 schrieb Alan Stern:
> On Fri, 29 Jun 2007, Oliver Neukum wrote:
>
> > > There's a more fundamental problem with your approach, though. You
> > > can't just allocate the TD's, ED's, and whatnot right alongside the
> > > URB. These data structures generally have to be loc
On Fri, 29 Jun 2007, Oliver Neukum wrote:
> > There's a more fundamental problem with your approach, though. You
> > can't just allocate the TD's, ED's, and whatnot right alongside the
> > URB. These data structures generally have to be located in
> > DMA-consistent memory (or is it "DMA-coheren
Am Freitag, 29. Juni 2007 schrieb David Brownell:
> On Friday 29 June 2007, Oliver Neukum wrote:
> > Am Freitag, 29. Juni 2007 schrieb Greg KH:
>
> > > And, as a plus, it let's us break the api again :)
>
> We need a "megasmiley" glyph. ;)
>
>
> > I am very reluctant to do that. It makes preal
On Fri, 29 Jun 2007 14:09:23 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8690
>
>Summary: Bulk IN transfers hanging randomly on Intel ICHx USB
> EHCI HCD
>Product: Drivers
>Version: 2.5
> KernelVers
On Friday 29 June 2007, Oliver Neukum wrote:
> Am Freitag, 29. Juni 2007 schrieb Greg KH:
> > And, as a plus, it let's us break the api again :)
We need a "megasmiley" glyph. ;)
> I am very reluctant to do that. It makes preallocating the tds impossible.
> If anything, we should split apart th
On Fri, 29 Jun 2007, Branden Sletteland wrote:
> On 6/28/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Thu, 28 Jun 2007, Branden Sletteland wrote:
> >
> > > I am seeing an issue when going from kernel version 2.6.20.14 to
> > > 2.6.21 through 2.6.21.5 were my high speed devices are only being
>
Am Freitag, 29. Juni 2007 schrieb Greg KH:
> On Fri, Jun 29, 2007 at 09:26:33AM -0400, Alan Stern wrote:
> > On Fri, 29 Jun 2007, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > this proved harder than it looks like. I can use cdc-acm over ohci with
> > > this patch. So what do you think?
> >
> >
On Fri, Jun 29, 2007 at 09:26:33AM -0400, Alan Stern wrote:
> On Fri, 29 Jun 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > this proved harder than it looks like. I can use cdc-acm over ohci with
> > this patch. So what do you think?
>
> It tries to do an awful lot all at once. A good place to st
On 6/28/07, Alan Stern <[EMAIL PROTECTED]> wrote:
On Thu, 28 Jun 2007, Branden Sletteland wrote:
> I am seeing an issue when going from kernel version 2.6.20.14 to
> 2.6.21 through 2.6.21.5 were my high speed devices are only being
> recognized as full speed devices, with error output on a 2.6.2
Am Freitag, 29. Juni 2007 schrieb Alan Stern:
> On Fri, 29 Jun 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > this proved harder than it looks like. I can use cdc-acm over ohci with
> > this patch. So what do you think?
>
> It tries to do an awful lot all at once. A good place to start would
> b
On Fri, 29 Jun 2007, Oliver Neukum wrote:
> Hi,
>
> this proved harder than it looks like. I can use cdc-acm over ohci with
> this patch. So what do you think?
It tries to do an awful lot all at once. A good place to start would
be to use separate allocation for the Iso packet structures. Thi
Hi,
this proved harder than it looks like. I can use cdc-acm over ohci with
this patch. So what do you think?
Regards
Oliver
--
diff -urp linux-2.6.22rc6vanilla/include/linux/usb.h
linux-2.6.22-rc6-storage/include/linux/usb.h
--- linux-2.6.22rc6vanilla/include/linux/usb.
Am Freitag, 29. Juni 2007 schrieb David Brownell:
> On Friday 29 June 2007, Oliver Neukum wrote:
> > Hi,
> >
> > I am trying to calculate worst cases memory requirements of EHCI.
> > For bulk transfers it seems to me that you need size/16384 (rounded up)
> > qtd and one qh. Is it really that easy?
On Friday 29 June 2007, Oliver Neukum wrote:
> Hi,
>
> I am trying to calculate worst cases memory requirements of EHCI.
> For bulk transfers it seems to me that you need size/16384 (rounded up)
> qtd and one qh. Is it really that easy?
ISTR, yes. And interrupt transfers are the same.
> What ab
Hi,
I am trying to calculate worst cases memory requirements of EHCI.
For bulk transfers it seems to me that you need size/16384 (rounded up)
qtd and one qh. Is it really that easy?
What about the other transfer types?
TIA
Oliver
-
Rodolfo Giometti wrote:
> On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote:
>> Let's start with *JUST* a driver, not trying to update everything
>> else in the USB Gadget stack so that it looks like it's designed
>> specifically to handle all of Intel's design botches related to
>> en
David Brownell wrote:
> On Thursday 28 June 2007, Rodolfo Giometti wrote:
>
>> As suggest by Leo let me propose to you my new patch for PXA27x UDC
>> support.
>>
>> Please, let me know what I have to do for kernel inclusion. :)
>
> Let's start with *JUST* a driver, not trying to update everything
>
On Thu, Jun 28, 2007 at 02:53:22PM -0700, David Brownell wrote:
>
> Let's start with *JUST* a driver, not trying to update everything
> else in the USB Gadget stack so that it looks like it's designed
> specifically to handle all of Intel's design botches related to
> endpoint config ... and work
On Fri, 29 Jun 2007 12:14:24 +0800
Lonsn <[EMAIL PROTECTED]> wrote:
> In
> the board side, kernel repeatedly printed following message every
> several seconds. "g_file_storage gadget: full speed config #1".
> What's wrong with it?
This usually means that the host gets confused about something the
Hi,
* David Brownell <[EMAIL PROTECTED]> [070529 18:02]:
> On Tuesday 29 May 2007, Tony Lindgren wrote:
>
> > > > (Peripheral maintains _both_ b_hnp_enable set by
> > > > a_host and user preference on b_device on using
> > > > b_hnp_enable)
> > >
> > > That "user preference" is problematic
27 matches
Mail list logo
