On Thu, 2006-06-08 at 10:34 +0200, Pavel Machek wrote:
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const
Hi,
On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+ * spitz is unable to properly power wireless card
+ * claiming 500mA -- usb interface work but wireless
+
Hi,
I have the isp116x running fine on my ixp425 platform under kernel
2.4.27-uc1, where it maps to IXP425_EXP_BUS_CS4_BASE_VIRT = 0xf400
(the 2.4.27 driver does not perform ioremap). However with kernel -
2.6.12, (same platform and settings as in the 2.4.27 case) I provide the
physical
Hi ,
i am testing the ehci-hcd river for ARC HS OTG controller. I have the
following observations
when i try connecting devices.
After the probe, the POTRSCx values are 0x8c001000 for ARC controller
whcih is EHCI complaint.
COMMAND: 0x80b01
MODE: 0x7
STATUS: 0x88
INTERRUPT: 0x37
SET INTR
feladó: Alan Stern
On Wed, 7 Jun 2006, Zoltan Karcagi wrote:
If you apply this patch instead of yours:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb/usbhid-remove-unneeded-blacklist-entries.patch
does the device then work?
Alan,
Hi!
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index acde886..1d8b58c 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
/* Select Power Management Mode */
Hi,
We have a Cypress based usb keyboard software that enumerates as a
USB Keyboard and works properly in Windows 32 / 64 bit platforms.
When it is connected to Linux, the device enumerates as a keyboard
with proper configurations. But whatever keystrokes we send to the
host are lost. I
Hi!
If that does the job we need to somehow inherit the power supply maximum
from
PCI when we allocate the root hub's device structure.
I don't think there is such a convention that's generic for PCI. There
might
be ACPI-specific tables holding that value, but on embedded
Hi,
I am writing a Linux USB driver and got stuck trying to get the probe function
working.
The driver is for a USB 1.1 device with 2 interrupt endpoints (in/out). I have
several of these devices attached (they are controlling one gyroscope and 8
motors on a mobile robot platform), and working
This limits power budget on spitz to 250mA. I'm not sure if it is the
right value, but it is certainly better than default 500mA, and
prevents nasty failure mode with zd1201.
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
PATCH FOLLOWS
KernelVersion: 2.6.17-rc6-git
diff --git
On Thu, 8 Jun 2006, Zoltan Karcagi wrote:
I noticed that in your original submission. Do you know what the second
interface is for?
Just guessing here: all the mouse related stuff (that's for sure),
wireless link quality and battery level monitoring, and maybe all the
extra buttons
On Thu, 8 Jun 2006 12:21:14 +0200, Sven Moellers [EMAIL PROTECTED] wrote:
I am suspecting another driver gets probed and claims the device [...]
Make sure your old usbfs based app wasn't running.
Other than this the source looks perfect, it must work.
Look at /proc/bus/usb/devices, it shows
On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
Hi,
On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
+* spitz is unable to properly power
On Thursday 08 June 2006 10:09 am, Russell King wrote:
On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
Hi,
On Thu, 2006-06-08 at 11:02 +0200, Pavel Machek wrote:
+ if (machine_is_spitz()) {
+ /* Warning, not coming from any official docs. But
Begin forwarded message:
Date: Thu, 8 Jun 2006 11:39:33 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6667] New: usb keyboard (vendor: E5) doesn't work
http://bugzilla.kernel.org/show_bug.cgi?id=6667
Summary: usb keyboard (vendor: E5) doesn't work
On Thursday 08 June 2006 5:21 am, [EMAIL PROTECTED] wrote:
Hi,
[ don't cc digest lists ... and avoid ccing multiple lists! ]
I am using ACER Aspire 3003LC laptop. Linux version: 2.6.15.4. I my
Host Controller supports Power Management.
That's with a SIS southbridge, right? With both
Hi David,
I'm currently working on fixing possible disconnect races in a USB-WLAN
driver, and to start with I'm trying to convince myself that such races
don't exist in other USB networking drivers (and why).
I had a quick look at usbnet, and decided that one such possible race
could occur
On Thu, 2006-06-08 at 11:26 -0700, David Brownell wrote:
On Thu, Jun 08, 2006 at 10:22:50AM +0100, Richard Purdie wrote:
Just because the omap does it that way, doesn't mean it can't be done
better ;-).
Agreed that platform_data is a better approach overall for holding that
power budget.
On Wed, 7 Jun 2006 15:40:13 -0700
Greg KH [EMAIL PROTECTED] wrote:
| On Wed, Jun 07, 2006 at 04:53:33PM -0300, Luiz Fernando N. Capitulino wrote:
|
| Hi Sergei,
|
| On Wed, 07 Jun 2006 21:54:16 +0400
| Sergei Organov [EMAIL PROTECTED] wrote:
|
| | Would it be a welcome contribution if
On Thu, 08 Jun 2006 09:16:17 +0400
Sergei Organov [EMAIL PROTECTED] wrote:
| Hi Luiz,
|
| Luiz Fernando N. Capitulino [EMAIL PROTECTED] writes:
| Hi Sergei,
| [...]
| I said 'current design' because the generic code could be merged
| with usbserial core with the libata-like design we
The PXA platform does have an existing mechanism to pass platform data
(I added it a while back). I've added
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
into the patch system replacing Pavel's version.
OK, I see now. Simple enough, better than the original. Go for
On Thu, 2006-06-08 at 13:38 -0700, David Brownell wrote:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
OK, I see now. Simple enough, better than the original. Go for it.
There was a PXA issue I was alluding to that's still open, though.
It's the way there's no
On Thursday 08 June 2006 2:22 pm, Richard Purdie wrote:
On Thu, 2006-06-08 at 13:38 -0700, David Brownell wrote:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3547/1
OK, I see now. Simple enough, better than the original. Go for it.
There was a PXA issue I was
On Thu, 2006-06-08 at 14:40 -0700, David Brownell wrote:
Right. OHCI was just an example though ... there are lots of other
platform drivers for PXA. I'm not sure they all check for platform_data
before succeeding in their probe() methods.
The implementations in mainline generally use all
On Thursday 08 June 2006 12:18 pm, Daniel Drake wrote:
However, netif_stop_queue() may return with transmissions still running
on other CPUs - I think netif_tx_disable() is what is needed, which
guarantees that no transmissions are active when it returns.
Do you agree that this is a
Hello David
Few dumb questions.
Where in the driver source code would like to insert the dbg_qh() and dbg_qtd()
?
Will turning on the ehci verbose debugging provide the information that you are
looking for?
Regards
Vivek
-Original Message-
From: David Brownell [mailto:[EMAIL
David Brownell wrote:
Hmm, most drivers call netif_stop_queue() rather than netif_tx_disable();
a quick conversation with Mr. Grep shows only three uses of the latter.
And with no documentation, it's a bit hard for me to agree (without diving
deeper into the network stack than I have time
On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote:
The easiest solution might be to move the ohci device registration into
pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
tested only so far).
Looked OK to me.
That's the kind of approach now used
ping
Franck Bui-Huu wrote:
When closing the device, the driver acquires/release twice the
port lock before/after waiting for the data to be completely
sent.
It also uses the generic scheduler function for waiting for an
event.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
On Thu, 8 Jun 2006, David Brownell wrote:
On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote:
One additional nuance: if
the kernel doesn't have that driver configured, that's another reason not
to bother registering its device.
This is where you start to add ugly ifdefs and
On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote:
You are both saying the same thing so far.
Hey, violent agreement is half the fun! :)
But here you argue that platform bus should not work that same way ... it
should register devices that can't be present. If nothing else, that's
On Thursday 08 June 2006 12:50 am, rakesh kn wrote:
1) When a OTG hard disk(Self Powered) was connected, there was no
interrupt and my ehci_irq interrupt handler was not invoked.
When i power on the device i get a DISCONNECT event from the device and the
PORTSCx value changes to 0x8c001002
On Monday 05 June 2006 1:31 pm, Perez-Gonzalez, Inaky wrote:
From: Pavel Machek [mailto:[EMAIL PROTECTED]
Is there any hardware available?
I think some companies are starting to make PDKs available this
summer, but YMMV.
Actually ISTR the WUSB team at www.usb.org had press releases
On Thu, 8 Jun 2006, David Brownell wrote:
On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote:
He replied to your assertion where you said: if the kernel doesn't have
that driver configured, that's another reason not to bother registering
its device to which he disagreed, and I
On Thursday 08 June 2006 12:50 am, rakesh kn wrote:
1) When a OTG hard disk(Self Powered) was connected, there was no
interrupt and my ehci_irq interrupt handler was not invoked.
When i power on the device i get a DISCONNECT event from the device and
the
PORTSCx value changes to
On Thursday 08 June 2006 7:36 pm, Steve Calfee wrote:
I am working on an ARM based OTG system. What is the otg disk drive?
I'm not the person who mentioned one of those. When I needed
such a beast, I've had to craft one with a Linux development
board. There's the USB-IF OTG test suite too.
On Thu, 8 Jun 2006, David Brownell wrote:
That said, I don't see an obvious race there. If the device disconnects,
there's now a guarantee that all pending urbs will have completed before
the driver disconnect() method is called. (As of maybe 2.6.8 or so. The
original 2.4 code of course
On Thursday 08 June 2006 8:26 pm, Alan Stern wrote:
On Thu, 8 Jun 2006, David Brownell wrote:
That said, I don't see an obvious race there. If the device disconnects,
there's now a guarantee that all pending urbs will have completed before
the driver disconnect() method is called. (As
On Thu, 8 Jun 2006, David Brownell wrote:
On Thursday 08 June 2006 8:26 pm, Alan Stern wrote:
On Thu, 8 Jun 2006, David Brownell wrote:
That said, I don't see an obvious race there. If the device disconnects,
there's now a guarantee that all pending urbs will have completed before
Hi David,
Infact i am working on the ARM based board with ARC OTG Contrller and
an SMSC USB3000 ULPI Transceiver, which has an mini-AB receptacle.
I connected the OTG Hard disk to a linux pc running kernel 2.6.11.10
using a Mini-B to Standard-A USB Cable. I could get the interrupt in
the linux
Hi all,
We are developing a device driver for a PCMCIA based USB Host
Controller.
We are facing an issue in the operation of the driver under X Windows.
In the PCMCIA client driver, we register a platform device.
Through this platform device, we are passing the resources to the Host
Controller
Am Donnerstag, 8. Juni 2006 23:55 schrieb David Brownell:
Maybe it'd be good to ask over on netdev whether that argument shouldn't
be applied to pretty much every network driver...
Yes
That said, I don't see an obvious race there. If the device disconnects,
there's now a guarantee that all
42 matches
Mail list logo
