Dear Sir,
Sorry to bother you. I'm newbie with develop usb mass storage for
bulk only and using SCSI primary command set under Embedded host platform.
But after reading of SPC-2 command set, I can't find READ_10 =
0x28(opcode). Only READ BUFFER available. Can anyone would tell me whi
On Mon, Jul 15, 2002 at 06:45:50PM -0700, David Brownell wrote:
> This patch:
>
> - Enables use of bulk queueing
> - Avoids stopping the tx queue until it's really needed
>
> If enabling bulk queuing causes any problems in any of the
> HCDs, we'll want to find out ... :)
>
> Please merge to Lin
Oliver Neukum wrote:
> Am Donnerstag, 18. Juli 2002 23:45 schrieben Sie:
>
>>>is there a deeper reason for the TDs being allocated under a spinlock?
>>
>>The presence of an annoying hashtable needed for bus_to_virt()
>>style mappings. Minimally, stuffing the hashbuckets needs to
>>be reentrant,
On Thu, 18 Jul 2002, David Brownell wrote:
> The SA- root hub init code is supposed to initialize dev->speed
> for its root hub ... SPEED_UNKNOWN is an error. A one-line fix ... :)
>
Seems like that was a problem with the old usb-ohci driver. I'm now using
ohci-hcd as Christopher suggest
Am Donnerstag, 18. Juli 2002 23:45 schrieben Sie:
> > is there a deeper reason for the TDs being allocated under a spinlock?
>
> The presence of an annoying hashtable needed for bus_to_virt()
> style mappings. Minimally, stuffing the hashbuckets needs to
> be reentrant, and that's done as part of
Hi,
currently there's a problem with storage. The vm may use it to page out
dirty pages in order to free memory. Unfortunately this operation needs memory
itself. The included patch should help the problem by retrying a failed memory
allocation
in ohci from the atomic pool. In the long run we ne
> is there a deeper reason for the TDs being allocated under a spinlock?
The presence of an annoying hashtable needed for bus_to_virt()
style mappings. Minimally, stuffing the hashbuckets needs to
be reentrant, and that's done as part of allocation.
After my next set of OHCI patches I hope to p
Hi,
is there a deeper reason for the TDs being allocated under a spinlock?
Regards
Oliver
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
> Thanks for the update. I was able to get it working by compiling as a
> module and adding a line to the case statment in urb.c in
> usb_submit_urb that was switching on dev->speed. I added a fall
> through for USB_SPEED_UNKNOWN to USB_SPEED_FULL. I don't know why the
> ADS Bitsy SA111 is retu
> > Looks like __init code calling __exit or __devexit code when
> > built into a module.
>
> 3. Here's the patch:
>
> --- linux-2.5.24-rmk1-ch2/drivers/usb/host/usb-ohci-sa.c.orig
> Wed Jul 17 18:29:21 2002
> +++ linux-2.5.24-rmk1-ch2/drivers/usb/host/usb-ohci-sa.c Thu Jul
> 18 10:16:09
On Thu, 18 Jul 2002, David Brownell wrote:
| > The Linux kernel typically achieves I/O rates of from 10-20 MBytes/sec
| > with the 2.4.19 kernel using readily available retail USB 2.0 hard
| > drives. These rates currently compare favorably with the speeds that
| > other operating systems achieve
> Most major Linux distributions will include USB 2.0 support in the
> near future. Redhat and Mandrake both currently include limited USB
> 2.0 support. Jason Ziller, chairman of the USB Implementers Forum,
> said "I am excited about Hi-Speed USB 2.0 being included in the latest
> Linux kernel.
> > > drivers/built-in.o: In function `sa_ohci_init':
> > > drivers/built-in.o(.text.init+0x3bb4): relocation truncated
> > > to fit: R_ARM_PC24 text.exit
> > > drivers/built-in.o(.text.init+0x3c08): relocation truncated
> > > to fit: R_ARM_PC24 text.exit
> >
>
> Looks like __init code call
On Wed, 17 Jul 2002, Duncan Sands wrote:
> Hi Dave, it is the same with both UHCIs. I've been looking
> at where the port reset (which kills the modem) actually happens.
> It is in uhci-hub.c, in the routine uhci_hub_control (case SetPortFeature).
> The code is as follows (not my favorite coding
14 matches
Mail list logo
