On 21/01/2006 6:47 p.m., Andrew Morton wrote:
I've now done in excess of 20 reboots with this code and haven't had either
problem show up at all.
So for now I'll keep a record of things for a bit longer, but I guess I've
reason to be fairly confident that both this USB/IRQ problem and my AT
Reuben Farrelly <[EMAIL PROTECTED]> wrote:
>
>
>
> On 16/01/2006 4:46 p.m., Alan Stern wrote:
> > On Mon, 16 Jan 2006, Reuben Farrelly wrote:
> >
> >>> From the information presented here, it looks like -mm1 correctly routes
> >>> the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169
On 16/01/2006 4:46 p.m., Alan Stern wrote:
On Mon, 16 Jan 2006, Reuben Farrelly wrote:
From the information presented here, it looks like -mm1 correctly routes
the 1d.1 controller to IRQ 193 and the 1d.3 controller to IRQ 169, whereas
-mm3 incorrectly routes the 1d.3 controller to IRQ 193. T
On Fri, 20 Jan 2006, Pete Zaitcev wrote:
> Looks like an inverted condition. Maybe it was meant to be a de-Morgan
> of "uses new polling and has an URB for that". Not sure though...
No, I think it's correct as written.
The idea is that if a driver uses the new polling, the poll should
always o
On Fri, 20 Jan 2006, Pete Zaitcev wrote:
> If the above theory is correct, the only way NO_FSBR flag can help is
> because it prevents us from switching TDs into UHCI_PTR_DEPTH mode
> in uhci_fsbr_timeout. This is something I do not understand completely
> yet.
The newest drivers don't use depth-
On Fri, 20 Jan 2006, Frantz, Chris wrote:
> Alan,
>
> On my controller, PEC turns on as soon as the controller begins the
> reset condition. CSC turns on as soon as the controller ends the reset
> condition (e.g. in response to PORT_RESET getting cleared).
>
> So, the loop exit condition should
On Saturday 21 January 2006 00:43, Pete Zaitcev wrote:
> Looks like an inverted condition. Maybe it was meant to be a de-Morgan
> of "uses new polling and has an URB for that". Not sure though...
>
> diff -upr -X dontdiff linux-2.6.16-rc1/drivers/usb/core/hcd.c
> linux-2.6.16-rc1-lem/drivers/usb/co
We know we can set dev_addr and host_addr when we insert g_ether module,
so that each peripheral reuses the same unique hw address every time it
boots. but how can we set the same unique host's ipaddress when using
rndis, so that host user don't need to set ipaddress byhand, and we
don't need to us
On Friday 13 January 2006 10:30 am, Jordan Crouse wrote:
> ALCHEMY: Add EHCI support for AU1200
Unfortunately it doesn't apply to my current tree, and I see that
you were reverting some of the updates in current kernel GIT ...
Please let me know if the updated version I'm posting does not
behave
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falka
This one's a bit experimental yet, but it acts OK for me;
unclear if it'll solve anyone else's problems with unlinking
things from the async ring though.
This patch modifies the behavior of the EHCI driver in an unlink path
that seems to be causing various issues on some systems. Those problems
Some platforms are picky about the length reported when freeing
dma-coherent buffers. They're happier with this patch.
This makes sure that the correct length is reported when freeing
a dma-coherent buffer; some platforms complain if that's wrong.
It also makes two parameters readonly in sysfs, a
This patch is from Clemens Ladisch, and should make full speed ISO
transfers work better.
From [EMAIL PROTECTED] Mon Jan 9 10:09:27 2006
This patch replaces the split ISO raw_mask calculation code in the
iso_stream_init() function that computed incorrect numbers of high
speed transactions for bot
This adds OHCI support for another MIPS based SOC; in this
case it's a slight variant of other Au1xxx chips.
ALCHEMY: Add OHCI support for AU1200
Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
Updated by moving the OHCI support out of the EHCI patch.
Signed-off-by: David Brownell <[EMAIL PRO
When using device authentication, there are two more states to
be traversed during the key exchange. Might as well declare
them.
Another hook needed for wireless USB: there are states associated with the
device authentication protocol. Wireless devices must authenticate using
the host system's k
Support for EHCI on a second SOC, this one MIPS not PPC.
(And there's support on the way for an ARM/XScale SOCI too...)
ALCHEMY: Add EHCI support for AU1200
Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
Updated by removing the OHCI support
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
I
This is a non-PCI implementation of EHCI found on a Freescale SOC.
Adding a Host Mode USB driver for the Freescale 83xx.
This driver supports both the Dual-Role (DR) controller and the
Multi-Port-Host (MPH) controller present in the Freescale MPC8349. It has
been tested with the MPC8349CDS referen
This works around a silicon erratum.
From [EMAIL PROTECTED] Fri Jan 20 11:52:57 2006
On the MPC834x processors the multiport host (MPH) EHCI controller has an
erratum in which the port number in the queue head expects to be 0..N-1
instead of 1..N. If we are on one of these chips we subtract one f
Some older NF2 parts don't implement selective suspend correctly, and
this workaround improves things slightly.
This teaches the EHCI driver about a quirk seen in older NForce2 chips,
adding a workaround to ignore selective suspend requests. Bus-wide
(so-called "global") suspend still works, as d
Looks like an inverted condition. Maybe it was meant to be a de-Morgan
of "uses new polling and has an URB for that". Not sure though...
diff -upr -X dontdiff linux-2.6.16-rc1/drivers/usb/core/hcd.c
linux-2.6.16-rc1-lem/drivers/usb/core/hcd.c
--- linux-2.6.16-rc1/drivers/usb/core/hcd.c 2006-0
On Fri, 20 Jan 2006 11:16:04 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote:
> I've been meaning to get back to you about this. The latest kernels
> (those that use check_fsbr() instead of stall_callback) don't seem to
> suffer from the same problem.
>[...]
> I'm not exactly sure what should be
On Fri, 20 Jan 2006 09:33:26 +0100 (CET), Guennadi Liakhovetski <[EMAIL
PROTECTED]> wrote:
> Looks like a bug?
> --- a/drivers/usb/host/usb-uhci.c Fri Jan 20 09:27:50 2006
> +++ b/drivers/usb/host/usb-uhci.c Fri Jan 20 09:28:05 2006
> @@ -2505,7 +2505,7 @@
> ((urb_p
Alan,
On my controller, PEC turns on as soon as the controller begins the
reset condition. CSC turns on as soon as the controller ends the reset
condition (e.g. in response to PORT_RESET getting cleared).
So, the loop exit condition should be (inw(port_addr) & CSC).
I'll prototype this change o
On Fri, Jan 20, 2006 at 09:33:26AM +0100, Guennadi Liakhovetski wrote:
> Hi
>
> Looks like a bug?
Looks like you're right.
Marcelo, I've merged it into -upstream.
> Thanks
> Guennadi
Thanks,
Willy
> -
> Guennadi Liakhovetski, Ph.D.
> DSA Daten- und Systemtechni
On Fri, 20 Jan 2006, Frantz, Chris wrote:
> The hardware is already shipping, so we can't switch controllers. I
> haven't examined the code thouroughly enough to fully understand it yet.
> Was there something wrong with the way the code worked in earlier
> kernels?
There was no spinlock protecti
Alan,
> I'm not sure about that. The delay occurs with a spinlock held and
interrupts
> disabled, and 250 us is a pretty long time to wait with interrupts
turned off.
> Some people might get annoyed.
> There are other ways of accomplishing the same thing, but they are
more
> difficult. Do you
On Fri, 20 Jan 2006, Pete Zaitcev wrote:
> On Fri, 20 Jan 2006 11:58:59 -0600 (CST), Kumar Gala <[EMAIL PROTECTED]>
> wrote:
>
> > "Port number in the Queue head is 0 to N-1. It should be 1 to N according
> > to EHCI spec. This bug only affects the host mode."
> >
> > Would something like the
On Thu, Jan 19, 2006 at 05:11:32PM -0800, Greg KH wrote:
> On Thu, Jan 19, 2006 at 02:18:54AM +0100, Adrian Bunk wrote:
> > This patch contains the following possible cleanups:
> > - make needlessly global functions static
> > - function and struct declarations belong into header files
> > - make S
On Fri, 20 Jan 2006, Frantz, Chris wrote:
> Pete,
>
> I do, unforunately, have a different problem that I may need your and
> Alan's help on. It seems the uhci hub implementation has changed
> slighly. In older kernels (2.6.9/2.6.10/2.6.11 timeframe), the uhci hub
> portion of the driver had a
On Fri, 20 Jan 2006, Kumar Gala wrote:
> > > + /* Some Freescale processors have an errata in which the
> > > + * port number in the queue head was 0..N-1 instead of 1..N.
> > > + */
FYI, "errata" is plural; it means "errors". The correct singular term is
"erratum", me
On Fri, 20 Jan 2006 11:58:59 -0600 (CST), Kumar Gala <[EMAIL PROTECTED]> wrote:
> "Port number in the Queue head is 0 to N-1. It should be 1 to N according
> to EHCI spec. This bug only affects the host mode."
>
> Would something like the following patch be acceptable?
> +#ifdef CONFIG_PPC_83xx
On Fri, 20 Jan 2006, David Brownell wrote:
> On Friday 20 January 2006 9:58 am, Kumar Gala wrote:
> > David,
> >
> > I was hoping to get your feedback on how you would like to handle an
> > errata that Freescale has in their EHCI controllers. Their multiport host
> > controller has the followi
On the MPC834x processors the multiport host (MPH) EHCI controller has an
errata in which the port number in the queue head expects to be 0..N-1
instead of 1..N. If we are on one of these chips we subtract one from
the port number before putting it into the queue head.
Signed-off-by: Kumar Gala <
On Fri, 20 Jan 2006, Bahadir Balban wrote:
> Hi,
>
> % dd if=/dev/sda count=1 | hexdump
>
> gives all zeroes. If I increase count, occasionally some data shows up
> which isn't meaningful ascii, but mostly zero.
If you really do get all zeros then the partition sector is empty. Hence
there ar
Pete,
I do, unforunately, have a different problem that I may need your and
Alan's help on. It seems the uhci hub implementation has changed
slighly. In older kernels (2.6.9/2.6.10/2.6.11 timeframe), the uhci hub
portion of the driver had a rather long delay (10 ms) between clearning
root-hub po
On Friday 20 January 2006 1:09 am, Mukund JB. wrote:
>
> Dear All,
>
> I am trying to settle some more clarification regarding the USB devices.
> Can someone please clarify the following?
>
> 1) OHCI & UHCI are the interfaces developed which with USB 1.1 devices.
> 2) EHCI is interfaces develope
On Friday 20 January 2006 9:58 am, Kumar Gala wrote:
> David,
>
> I was hoping to get your feedback on how you would like to handle an
> errata that Freescale has in their EHCI controllers. Their multiport host
> controller has the following errata:
>
> "Port number in the Queue head is 0 to N
> On 1/20/06, Alan Stern <[EMAIL PROTECTED]> wrote:
>> What do you get from "dd if=/dev/sda count=1 | hexdump -C"?
>>
>> Alan Stern
>>
>
> Hi,
>
> % dd if=/dev/sda count=1 | hexdump
>
> gives all zeroes. If I increase count, occasionally some data shows up
> which isn't meaningful ascii, but mostly
On 1/20/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> What do you get from "dd if=/dev/sda count=1 | hexdump -C"?
>
> Alan Stern
>
Hi,
% dd if=/dev/sda count=1 | hexdump
gives all zeroes. If I increase count, occasionally some data shows up
which isn't meaningful ascii, but mostly zero. The same f
David,
I was hoping to get your feedback on how you would like to handle an
errata that Freescale has in their EHCI controllers. Their multiport host
controller has the following errata:
"Port number in the Queue head is 0 to N-1. It should be 1 to N according
to EHCI spec. This bug only affe
Greetings,
In rebuilding the code, GCC complained about a statement with no
effect. I traced it to a malformed statement which was missing an '='.
The fix is attached.
Randy Vinson
MontaVista Software
Adding a missing '='.
Signed-off-by: Randy Vinson <[EMAIL
On Fri, 20 Jan 2006 11:16:04 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote:
> I've been meaning to get back to you about this. The latest kernels
> (those that use check_fsbr() instead of stall_callback) don't seem to
> suffer from the same problem. It seems that those kernels don't keep
> tr
Pete,
I've been meaning to get back to you about this. The latest kernels
(those that use check_fsbr() instead of stall_callback) don't seem to
suffer from the same problem. It seems that those kernels don't keep
track of individual transfers and mess with whether or not FSBR is on or
off.
On e
> experiencing the same problem after all. I feel so alone again...
However, at least temperatur goes slightly up (2K) wenn i load ehci-hcd
and I can confirm the ASYNC problem:
bus pci, device :00:10.3 (driver 10 Dec 2004)
EHCI Host Controller
EHCI 1.00, hcd state 1
ownership 0101 linux
S
Helmut Toplitzer wrote:
Rene: Could you please try this out?
Yes, but please note I don't have a VIA southbridge (an AMD756), only
the VIA VT6212L EHCI controller. I commented the
#if defined(CONFIG_BLK_DEV_VIA82CXXX)
bit.
I'm currently working with it and it looks good.
Transfer rate is
On Fri, 20 Jan 2006, Bahadir Balban wrote:
> Hi,
>
> I am testing a new hc driver. My intention is to mount a usb flash
> disk. The problem is that the device is recognised properly by the
> message:
>
> usb 1-1.3: Product: DiskOnKey
> usb 1-1.3: Manufacturer: M-Sys
> usb 1-1.3: SerialNumber: 02
Hi,
I am testing a new hc driver. My intention is to mount a usb flash
disk. The problem is that the device is recognised properly by the
message:
usb 1-1.3: Product: DiskOnKey
usb 1-1.3: Manufacturer: M-Sys
usb 1-1.3: SerialNumber: 020DC31535004726
scsi0 : SCSI emulation for USB Mass Storage dev
>
> Some stylistic suggestions. The new routines should be surrounded by
>
> #if defined(CONFIG_BLK_DEV_VIA82CXXX) and defined(HAVE_VIA_HALT)
>
> In the #else part, make ide_disable_hlt and ide_enable_hlt inline.
>
> You don't need the #ifdef protecting the calls to to ide_disable_hlt and
> ide_en
The email was deleted by system policy.
Attached file might be containing virus.
Connection From: 127.0.0.1
From: linux-usb-devel@lists.sourceforge.net
To: [EMAIL PROTECTED]
Date: Fri, 20 Jan 2006 18:21:42 +0900
Subject: Re:
--- Scan information follows ---
Virus Name: [EMAIL PROTECTED]
File At
Dear All,
I am trying to settle some more clarification regarding the USB devices.
Can someone please clarify the following?
1) OHCI & UHCI are the interfaces developed which with USB 1.1 devices.
2) EHCI is interfaces developed which with USB 2.0 devices. So, if it is
USB 2.0 Host controller, m
On Fri, 20 Jan 2006, Sebastian Haas wrote:
> Hello!
>
> At the moment I'm optimizing a USB driver for a "USB 1.1 Full Speed" device.
>
> And what I want to know is if it is possible to submit a URB which is
> bigger then the maximal allowed endpoint packet size? Will the HCD
> driver or the US
Hello!
At the moment I'm optimizing a USB driver for a "USB 1.1 Full Speed" device.
And what I want to know is if it is possible to submit a URB which is
bigger then the maximal allowed endpoint packet size? Will the HCD
driver or the USB controller split the packet into several e.g. 64bytes
pack
Hi
Looks like a bug?
Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
Signed-off-by Guennadi Liakhovetski <[EMAIL PROTECTED]>
--- a/drivers/usb/host/usb-uhci.c Fri Jan 20 09:27:50 2006
++
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=5777
>
> Summary: ehci-hcd re-load necessary to use kbd on docking station
> hub
> Kernel Version: 2.6.13, 2.6.15-rc6
Seems to be a fairly recent regression.
---
54 matches
Mail list logo
