From: David Brownell <[EMAIL PROTECTED]>
To: [email protected]
CC: "Steve Calfee" <[EMAIL PROTECTED]>
Subject: Re: [linux-usb-devel] Re: Question about OTG operations
Date: Tue, 28 Feb 2006 23:42:35 -0800
On Tuesday 28 February 2006 11:03 pm, Steve Calfe
On Tuesday 28 February 2006 11:03 pm, Steve Calfee wrote:
> Yes, it is a huge drawback to the spec. Being host does not say you provide
> power, being "A" connector does. How do you communicate the fact that your
> handheld can use and get power from a device if it is plugged in properly.
That
From: David Brownell <[EMAIL PROTECTED]>
To: "Steve Calfee" <[EMAIL PROTECTED]>
CC: [email protected]
Subject: Re: [linux-usb-devel] Re: Question about OTG operations
Date: Tue, 28 Feb 2006 22:46:42 -0800
On Tuesday 28 February 2006 10:20 pm, Steve C
From: Li Yang-r58472 <[EMAIL PROTECTED]>
To: Steve Calfee <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
CC: [email protected]
Subject: RE: [linux-usb-devel] Re: Question about OTG operations
Date: Wed, 1 Mar 2006 14:44:31 +0800
> -Original Message-
> From
On Tuesday 28 February 2006 10:20 pm, Steve Calfee wrote:
> So for instance if you have a battery powered PC and wish to connect it to a
> powered printer or a display device it would be nice if the A connector goes
> into the "peripheral" and the b into the "computer" that way the computer
> w
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Steve
> Calfee
> Sent: Wednesday, March 01, 2006 2:21 PM
> To: [EMAIL PROTECTED]
> Cc: [email protected]
> Subject: RE: [linux-usb-devel] Re: Question about
> -Original Message-
> From: David Brownell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 01, 2006 12:59 PM
> To: Li Yang-r58472
> Cc: [email protected]
> Subject: Re: Question about OTG operations
>
> On Tuesday 28 February 2006 7:44 pm, Li Yang-r58472 wrote:
> >
On Tuesday 28 February 2006 7:44 pm, Li Yang-r58472 wrote:
> Thanks Dave,
>
> So the current application of HNP is only to correct wrongly connected
cable?
That's not what I said, but it _is_ the only scenario that's completely
spelled out in the specs.
One other really useful aspect of OTG
On Tuesday 28 February 2006 7:44 pm, Li Yang-r58472 wrote:
> Thanks Dave,
>
> So the current application of HNP is only to correct wrongly connected cable?
That's not what I said, but it _is_ the only scenario that's completely
spelled out in the specs.
Once HNP is enabled, if the host side inte
Thanks Dave,
So the current application of HNP is only to correct wrongly connected cable?
I don't think it's the original target of adding OTG to USB. Though we don't
have much examples of OTG usage in the market, I do think OTG is to add the
peer-to-peer ability to the previous client/serve
FYI the original didn't make it to the list due to an HTML attachment.
On Tue, 28 Feb 2006, David Brownell wrote:
> On Tuesday 28 February 2006 4:15 am, Li Yang-r58472 wrote:
> >
> > I'm doing OTG support on a Freescale PowerPC platform.
> > The basic ID specified role change can work correctly.
On Tuesday 28 February 2006 4:15 am, Li Yang-r58472 wrote:
>
> I'm doing OTG support on a Freescale PowerPC platform.
> The basic ID specified role change can work correctly.
Good ... that's the first milestone! I'm assuming you're
using a 2.6.10 (or newer) kernel, since that's where the
first O
On 13/12/05 09:35, tong changda wrote:
I see qualcomm's inf file that has this %xxx% =
QportInstall6k, SB\VID_1234&PID_&MI_01 %xxx% = QportInstallNMEA,
USB\VID_1234&PID_&MI_02 xxx% = QportInstalltest,
USB\VID_1234&PID_&MI_00 all this three has same VID&PID, diff only
on
On Wed, Feb 16, 2005 at 12:43:14PM -0500, Dan Streetman wrote:
>
> On Wed, 16 Feb 2005, Vojtech Pavlik wrote:
>
> >It doesn't flip them while it should flip the Y coordinate. This is
> >because many touchscreens have [0,0] in their bottom left corner by
> >hardware, being in the 1st quadrant, whi
On Tue, Feb 15, 2005 at 06:40:37PM -0500, Dan Streetman wrote:
>
> Hi Vojtech,
>
> I have a question about the "contract" of the evdev interface...
>
> I have 2 touch screens, both USB. Both of them have drivers (hid-input
> and mtouchusb) that provide ABS_X and ABS_Y coordinates to the input
On Tue, Jul 13, 2004 at 12:58:47PM +0530, Amol Kailash wrote:
> Hi,
>
> I am trying to write/understand the working of a USB bluetooth driver
> by using bluetooth tty driver using bluetooth.c (by Greg
> Kroah-Hartman) found in kernel source. I am aware of the hci_usb bluez
> source, tested it and
Am Mittwoch, 28. Januar 2004 11:44 schrieb Brad Hards:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sun, 25 Jan 2004 22:20 pm, Oliver Neukum wrote:
> > Aren't keys who are advertising themselves in that way according to the
> > standard declaring themselves not to be keyboards? It seem
On Wed, Jan 28, 2004 at 01:27:35PM +0100, Oliver Neukum wrote:
> Am Mittwoch, 28. Januar 2004 11:44 schrieb Brad Hards:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Sun, 25 Jan 2004 22:20 pm, Oliver Neukum wrote:
> > > Aren't keys who are advertising themselves in that way acco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 25 Jan 2004 22:20 pm, Oliver Neukum wrote:
> Aren't keys who are advertising themselves in that way according to the
> standard declaring themselves not to be keyboards? It seems to me that
> such devices should use the system control usage of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 09 Jan 2004 20:12 pm, Vojtech Pavlik wrote:
> > I have been notified that there are devices of this type which would
> > rather be accessed through hiddev. Reading the usage page specification
> > which calls such devices "application specific"
Am Sonntag, 25. Januar 2004 02:38 schrieb Brad Hards:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Fri, 09 Jan 2004 20:12 pm, Vojtech Pavlik wrote:
> > > I have been notified that there are devices of this type which would
> > > rather be accessed through hiddev. Reading the usage page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, wrong reply option in KMail.
- -- Forwarded Message --
Subject: Re: [linux-usb-devel] Re: question on hid usage pages
Date: Sun, 25 Jan 2004 22:28 pm
From: Brad Hards <[EMAIL PROTECTED]>
To: Oliver Neukum <[EMAIL
On Fri, Jan 09, 2004 at 09:42:51AM +0100, Oliver Neukum wrote:
> Am Freitag, 9. Januar 2004 08:35 schrieb Vojtech Pavlik:
> > On Fri, Jan 09, 2004 at 01:08:40AM +0100, Oliver Neukum wrote:
> >
> > > Hi Vojtech, hi list,
> > >
> > > could someone tell me why hid accepts devices with usage page 0xc
Am Freitag, 9. Januar 2004 08:35 schrieb Vojtech Pavlik:
> On Fri, Jan 09, 2004 at 01:08:40AM +0100, Oliver Neukum wrote:
>
> > Hi Vojtech, hi list,
> >
> > could someone tell me why hid accepts devices with usage page 0xc as input
> > devices in this check from hid.h:
> > #define IS_INPUT_APPLIC
On Fri, Jan 09, 2004 at 01:08:40AM +0100, Oliver Neukum wrote:
> Hi Vojtech, hi list,
>
> could someone tell me why hid accepts devices with usage page 0xc as input
> devices in this check from hid.h:
> #define IS_INPUT_APPLICATION(a) (((a >= 0x0001) && (a <= 0x00010008)) || (a ==
> 0x000100
David Brownell wrote:
> Yeouch! Microsoft's EHCI drivers? From what OS version?
> Identical hardware in both cases?
So i did the test:
Hardware: USB 2.0 storage (supporting max sectors = 240) connected to
usb extension PCI card.
Tested Partition: Partition 1 (18GB), FAT32
Filesize: 799MB
1: Wi
Alan Stern wrote:
> To be safest, I would choose multiples of 8. I don't know to what extent
> it matters.
The max. value i can choose is 135, but you said a multiple of 8 is
besser, so now i'm using value 128...
regards,
hampel
---
This SF
[EMAIL PROTECTED] wrote:
Alan Stern wrote:
This isn't diretly connected with the speed; it's more a question of how
much data can be sent in a single command. Setting max_sectors to 120
limits the driver to sending 60 KB at once (a sector is 512 bytes).
It's the only real throughput-restricting c
On Fri, 28 Nov 2003 [EMAIL PROTECTED] wrote:
> Alan Stern wrote:
> > Are you sure that _all_ values don't work? I would expect that at least
> > 128 would be okay. But no, I can't explain what's going on with your
> > device.
>
> I tried some values down until 140, all of them didn't work.
>
Alan Stern wrote:
> Are you sure that _all_ values don't work? I would expect that at least
> 128 would be okay. But no, I can't explain what's going on with your
> device.
I tried some values down until 140, all of them didn't work.
So i made a jump from 140 to 120 and this value is working n
On Thu, 27 Nov 2003, Kleiner Hampel wrote:
> Alan Stern wrote:
> > You will have to manually edit the file drivers/usb/storage/scsiglue.c in
> > your kernel source. Around about line 320 in the file you may or may not
> > see a line that says
> >
> > .max_sectors = 240,
> >
> > I
Alan Stern wrote:
> You will have to manually edit the file drivers/usb/storage/scsiglue.c in
> your kernel source. Around about line 320 in the file you may or may not
> see a line that says
>
> .max_sectors = 240,
>
> If it's there, try changing the 240 to 120. If it's not th
On Thu, 27 Nov 2003 [EMAIL PROTECTED] wrote:
> Would it help you knowing, that i tested an other usb 2.0 hard disk
> enclosure, that did work with kernel 2.6?
> But again, both work good with kernel 2.4.22.
It doesn't surprise me. There is only a small number of devices that work
with 2.4.22 an
Alan Stern wrote:
> Looking through the dmesg output isn't as useful as I had hoped. There
> are other differences between 2.4 and 2.6 that obscure the problem we're
> trying to solve.
>
> Don't be too surprised that something works under 2.4 and fails under 2.6!
>
> There have been a lot of
On Wed, 26 Nov 2003, Kleiner Hampel wrote:
> Am Mit, den 26.11.2003 schrieb Alan Stern um 16:28:
> > Interesting. It shows everything working at first, and then the device
> > fails at the first large (>64 KB) read.
> >
> > Is this using the EHCI driver (is it a high-speed connection)? I've se
Am Mit, den 26.11.2003 schrieb Alan Stern um 16:28:
> Interesting. It shows everything working at first, and then the device
> fails at the first large (>64 KB) read.
>
> Is this using the EHCI driver (is it a high-speed connection)? I've seen
> problems similar to yours on systems where the E
On Wed, 26 Nov 2003, Kleiner Hampel wrote:
> Hello,
>
> do you have any idea, how can i solve the usb 2.0 storage problem?
> I send you the dmesg output few days ago.
>
> regards,
> hampel
Sorry, I must have missed it.
Interesting. It shows everything working at first, and then the device
fa
what needs to be included to get 64bit DMA?
For a USB network driver, set NETIF_F_HIGHDMA.
Well, I should be more specific. What needs to be
#include
find /usr/src/linux/include -name '*.h' |xargs grep NETIF_F_HIGHDMA
---
This SF.Net email i
Am Montag, 23. Juni 2003 07:22 schrieb David Brownell:
> Oliver Neukum wrote:
> > what needs to be included to get 64bit DMA?
>
> For a USB network driver, set NETIF_F_HIGHDMA.
Well, I should be more specific. What needs to be
#include
Regards
Oliver
--
Oliver Neukum wrote:
what needs to be included to get 64bit DMA?
For a USB network driver, set NETIF_F_HIGHDMA.
- Dave
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer
Well, I haven't tested it with 2.5... I'm sure someone has, tho.
It is necessary to set the configuration to 1 on some devices.
I haven't seen a device that falls into this category with multiple
interfaces.
Matt
On Sun, Mar 30, 2003 at 02:53:59AM +0100, Oliver Neukum wrote:
> Hi,
>
> is the f
Hi,
But you don't check for asynchronousity, you check for in_interrupt().
Got patch? :)
Not the complicated patch you prefer. I don't know enough about ehci yet.
I'd likely kill the driver.
That's a one-liner. I think it won't actually affect much, but its
clearly wrong and should get f
Am Samstag, 18. Januar 2003 02:59 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Samstag, 18. Januar 2003 02:00 schrieb David Brownell:
> >>Oliver Neukum wrote:
> >>>Hi,
> >>>
> >>>regarding this piece of code:
> >>> spin_lock_irqsave (&ehci->lock, flags);
> >>> ...
> >>>
> >>>Does this
Oliver Neukum wrote:
Am Samstag, 18. Januar 2003 02:00 schrieb David Brownell:
Oliver Neukum wrote:
Hi,
regarding this piece of code:
spin_lock_irqsave (&ehci->lock, flags);
...
Does this mean that any call to usb_unlink_urb() for an URB on EHCI
with a spinlock held will fail?
No, but a
Am Samstag, 18. Januar 2003 02:00 schrieb David Brownell:
> Oliver Neukum wrote:
> > Hi,
> >
> > regarding this piece of code:
> > spin_lock_irqsave (&ehci->lock, flags);
> > ...
> >
> > Does this mean that any call to usb_unlink_urb() for an URB on EHCI
> > with a spinlock held will fail?
Oliver Neukum wrote:
Hi,
regarding this piece of code:
spin_lock_irqsave (&ehci->lock, flags);
...
Does this mean that any call to usb_unlink_urb() for an URB on EHCI
with a spinlock held will fail?
No, but a _synchronous_ one might need to wait_ms(1) for the relevant
hardware resource to be
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,
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
> 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
On Fri, 31 May 2002 04:53, [EMAIL PROTECTED] wrote:
> Quoting Brad Hards <[EMAIL PROTECTED]>:
> > Nope - hiddev
> > See http://www.frogmouth.net/hid-doco/linux-hid.html for incomplete
> > description. I'll update it over the weekend to the version I have here,
>
> Thanks, I can talk to the device
On Thu, 30 May 2002 [EMAIL PROTECTED] wrote:
>do I need to blacklist my device in the hid driver to prevent it from
>being grabbed?
If you are using usbfs/usbdevfs, use the new DISCONNECT ioctl to
remove HID from the interface you want. If you're not using
usbfs/usbdevfs (i.e. using HID/hiddev
Quoting Brad Hards <[EMAIL PROTECTED]>:
> Nope - hiddev
> See http://www.frogmouth.net/hid-doco/linux-hid.html for incomplete
> description. I'll update it over the weekend to the version I have here,
Thanks, I can talk to the device and issue ioctls now, and I'm figuring out how
to send and rec
On Wed, May 01, 2002 at 11:57:40AM -0700, Abhijeet Bisain wrote:
> Hi Greg,
>
> Thanks for the quick reply.
>
> I am using the generic usbserial driver. I do a modprobe usbserial to
> invoke and lsmod lists it as usbserial. The driver on windows is a custom
> driver and not a generic one.
A
Hi Greg,
Thanks for the quick reply.
I am using the generic usbserial driver. I do a modprobe usbserial to
invoke and lsmod lists it as usbserial. The driver on windows is a custom
driver and not a generic one.
What are some of the other drivers tuned for throughput? Do you have any
suggesti
On Wed, May 01, 2002 at 11:11:21AM -0700, Abhijeet Bisain wrote:
> Hi,
>
>I am trying to use the usbserial driver with a wireless modem. The
>driver tetects the device fine and I can setup ppp over the ttys in
> /dev/usb/tts directory. But my only issue is the throughput I get u
On Wed, May 01, 2002 at 11:11:21AM -0700, Abhijeet Bisain wrote:
> Hi,
>
>I am trying to use the usbserial driver with a wireless modem.
First off, which usbserial driver for which modem? The "generic"
driver, or another one?
> The
>driver tetects the device fine and I can set
56 matches
Mail list logo
