Title: RE: [linux-usb-devel] Including usb.h
Thanks but I was unfortunately working whith these options.
The problem comes from other files included in linux/usb.h when compiled with -D__KERNEL__
I am just doing tests for the moment to know how I can communicate with the device. I may not ne
David Brownell wrote:
>> > ACPI defines processor power-saving states C0, C1, C2 and C3. We cannot
>> > enter C3 if there is busmastering activity, and so we check BM_STS. If thi
>s
>> > is high when it should not be, and we are therefore not using C3, we are
>> > losing battery life.
>>
>> USB
I don't see how these patches work. (I may be confused - I've not had
any coffee yet :-)
- The hcca is allocated from consistent memory but then bus_to_virt is
used on the allocation (which will fail, at least on some
implementations).
- I think there is more than one place where the cache nee
I should have said I was talking about shutting down after
it gets the suspend request from PCI ... that is, when the
driver is told to stop activity so the system can suspend.
When OHCI is in the "UsbSuspend" state, it shouldn't
be accessing memory. And that's the state it enters
when it gets
On Tue, Mar 06, 2001 at 10:03:51PM -0800, Matthew Dharm wrote:
> You didn't send me the patch... :)
>
> Don't worry, newbie... it's a common mistake, even for the pros.
Time to get a brown paper bag...
diff -ur linux-2.4.1/drivers/usb/storage/unusual_devs.h
linux-2.4.1-taz/drivers/usb/storage
Hi Brad,
> - The hcca is allocated from consistent memory but then bus_to_virt is
> used on the allocation (which will fail, at least on some
> implementations).
That is, in hc_start() about line 2033? It should use ohci->hcca_dma,
not virt_to_bus(ohci->hcca), yes. Good catch! I'll send out a
Here's an updated patch. Fixes the issue Brad noted (below),
and adds a comment to the "history" section.
With this change, only the ED, TD, and data buffer manipulation
still use the problematic bus_to_virt() primitive.
- Dave
> > - The hcca is allocated from consistent memory but then bus_t
David Brownell wrote:
>Hi Brad,
>
>> - The hcca is allocated from consistent memory but then bus_to_virt is
>> used on the allocation (which will fail, at least on some
>> implementations).
>
>That is, in hc_start() about line 2033? It should use ohci->hcca_dma,
>not virt_to_bus(ohci->hcca), yes
David Brownell wrote:
> Hi Brad,
>
> > - The hcca is allocated from consistent memory but then bus_to_virt is
> > used on the allocation (which will fail, at least on some
> > implementations).
>
> That is, in hc_start() about line 2033? It should use ohci->hcca_dma,
> not virt_to_bus(ohci->hcca
Hi Michal-
> -Original Message-
> From: Michal Widera [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 06, 2001 2:22 AM
> To: Dunlap, Randy
> Subject: Re: [linux-usb-devel] Found Bug in Enumeration
>
>
> here is EXACT error message:
> from /var/log/messages
>
> Mar 2 10:02:12 localho
I am using the FTDI driver with a 8U232AM.
I have noticed the following issues:
Above 115.2K there are buffer overflows and dropped characters.
At 115.2K, I haven't seen any dropped characters but have seen the
following:
VFS: Mounted root (romfs filesystem) readonly.
Mounted devfs on /dev
Fr
[this is a resend]
Hi all,
Problem:
We are seeing the BM_STS bit stuck at 1, when the USB driver is enabled on
Linux.
Why this is important:
ACPI defines processor power-saving states C0, C1, C2 and C3. We cannot
enter C3 if there is busmastering activity, and so we check BM_STS. If this
is hig
Hello,
I have been trying to get my friend's modem working in Linux but
have had no luck so far. The modem is a Best Data 56USB-SP and the
ACM driver "recognises" its there. However, it will not let anything
be written to it or read from it. I tried doing:
echo "ATA" > /dev/usb/acm/0
and
On Tue, Mar 06, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > we also need to get rid of bus_to_virt().
>
> Hi Steve! Haven't forgotten about that. At the end of this
> message is the interface to what I'm working on just now.
> As in, coded but not debugged.
>
> This interface sort of c
We used pci_map_single() for the transfer buffer in my original version of
the StrongARM port. That way none of the drivers other than the controller
driver was affected.
Jamey
> -Original Message-
> From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 3:
> From: David Brownell <[EMAIL PROTECTED]>
> I should have said I was talking about shutting down after
> it gets the suspend request from PCI ... that is, when the
> driver is told to stop activity so the system can suspend.
> When OHCI is in the "UsbSuspend" state, it shouldn't
> be access
Hi everybody,
The USB stack is driving me nuts. I've found that changing the
transmit buffer from one place to another make the USB transfer
succedd or fail. This is absolutely crazy, so I would like someone to
explain me what's happening...
Context :
o kernel 2.4
On Wed, Mar 07, 2001, Jean Tourrilhes <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> The USB stack is driving me nuts. I've found that changing the
> transmit buffer from one place to another make the USB transfer
> succedd or fail. This is absolutely crazy, so I would like someone to
> > At the end of this
> > message is the interface to what I'm working on just now.
> > As in, coded but not debugged.
And attached is an updated version with an implementation that
seems to basically behave (barely tested, very untuned). It's a
good time for comments.
This uses per-page
> > When OHCI is in the "UsbSuspend" state, it shouldn't
> > be accessing memory. And that's the state it enters
> > when it gets the suspend request ... from ACPI, via PCI.
> > Right? Those PCI calls mean entering S3 or S4 states
> > it seems ... it's not clear to me whether there are enough
>
> There's a powerpoint presentation in the developer area of www.usb.org
> from last October, talking about power management and USB. One
> thing it says is that there ** IS ** a need for device
> drivers support for
> entering the C3 state ... which makes sense, since the USB
> device drivers
Regarding 2.4.2...
Why are the port feature defines (e.g. RH_PORT_ENABLE) all defined in each
HC's header file, and more importantly, why aren't they all using the define
(e.g. USB_PORT_FEAT_ENABLE) in hub.h?
I'm also wondering why the defines aren't consecutive.
Just curious -- Andy
-
Johannes Erdfelt wrote :
> The key is probably the function that calls irda_usb_change_speed_xbofs.
> Most likely it allocates self on the stack (as an automatic variable)
> which is not a valid memory location to DMA from and to.
No, self is not on the stack, I can guarantee you that. It
On Wed, Feb 28, 2001 at 10:01:07AM +, Alan Cox wrote:
> > we do this by using {u,m}delay, but we want to do this in a better way. Are
> > there any timers in the USB subsystem that we could make use of? We will
> > need a resolution in the 100us-1ms area. We have been thinking of sending
>
>
I must add the following entry to usb-storage.c to use TEAC CD-210PU
CD-ROM (shipped with NEC LaVie MX) on Linux 2.2.18. I wish it would
be included in the release.
Unfortunately, I did not try the device on Linux 2.4 as the OHCI
driver has another problem.
--
"Free software is not for free."
Ka
On Wed, Mar 07, 2001 at 06:35:31PM -0800, Jean Tourrilhes wrote:
> Johannes Erdfelt wrote :
> > The key is probably the function that calls irda_usb_change_speed_xbofs.
> > Most likely it allocates self on the stack (as an automatic variable)
> > which is not a valid memory location to DMA from an
On Wed, Mar 07, 2001 at 02:34:26PM -0500, [EMAIL PROTECTED] wrote:
> I found that a native UART has a latency of 1-2ms for a single byte.
> That latency increases with packet size. When run over the 8U232AM
> the 1 byte latency is about 16-17ms and remains about 15ms longer than
> the native UAR
> > (1) CONFIG_SLAB_DEBUG breaks the documented
> > requirement that the slab cache return adequately aligned
> > data ...
>
> adequately aligned for the _cpu_, not for some controllers. It's neither
> documented that HW_CACHEALIGN aligns to 16 byte boundaries
It's documented in mm/slab.c (line
28 matches
Mail list logo
