OHCI is claiming my USB 2.0 hub, connected to the built-in USB port
on my x86-64 notebook.
This happens on both 2.6.13.2 and 2.6.14-rc2:
ehci_hcd :00:13.2: new USB bus registered, assigned bus number 1
ehci_hcd :00:13.2: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB
I think I had some mistakes.
When I have searched in ML I have used 1161 rather than 116x.
When I have readed 116x-hcd driver page I don't have understand that is
the driver does not support iso trnsfers, not the host.
Excuse me to all the community.
Cristian Chiarello.
---
On Thu, 22 Sep 2005, Cristian Chiarello wrote:
> Hi @ all.
> I'm working on a custom EP7311 board with isp1161A1 and linux-2.4.21-rmk1.
> Another people have made porting of kernel to this board but now I have
> problem with data tranfert in ISO mode with a webcam logitech
> 4000pro: some frame
On Fri, Sep 23, 2005 at 06:05:37AM +0200, Oliver Neukum wrote:
> Am Freitag, 23. September 2005 00:49 schrieb David Kubicek:
> > Ok, so what does that mean for me now? Should I change those to normal
> > spin_locks too? Locks I used are not there "by design" it's just the way
> > a similar piece of
UDC can work well for several times (insmod and rmmod for several
times) ,but it may not get descriptor of GET_DESCRIPTOR once or twice . and
the PC can not recognize the device .after that happens , it will repeat for
times( it never mind rmmod and insmod the module, or plug in or out
> > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > irqsave. It will just be slower. But in a tasklet or interrupt handler
> > spin_lock() will do. Basically these locks differ in whether they shut down
> > irq processing on the local CPU. In interrupt it is down and mu
Begin forwarded message:
Date: Fri, 23 Sep 2005 00:32:01 -0400
From: Kurt Wall <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: GPF Using Quickcam
Evenin' all,
I was testing out my spiffy new (to me) QuickCam Express webcam, pressed
^C to terminate the test, and got the GPF shown
> Hi all
> I am porting the Linux EHCI usb driver for 2.6.9 kernel to 2.6.10 kernel
> During this i was facing following problems in compilation -
>
> 1) hcd_alloc function is not present , so i replaced it with usb_create_hcd
>
> 2) hcd_free function is not present , so i replaced it with hcd_buff
On Fri, Sep 23, 2005 at 11:41:54AM +0530, [EMAIL PROTECTED] wrote:
>
> Hello Greg ,
> What kernel version would you recommend for porting usb-serial driver
> for 2.4 ?
> (Considering the stablity of usb/usb-serial layer in 2.4)
No new distros are being created for 2.4, why would you want to port
Hi all
I am porting the Linux EHCI usb driver for 2.6.9 kernel to 2.6.10 kernel
During this i was facing following problems in compilation -
1) hcd_alloc function is not present , so i replaced it with usb_create_hcd
2) hcd_free function is not present , so i replaced it with hcd_buffer_destroy
> I don't know what's going on with 2.4, but I can answer your
> first question. USB_CONFIG_ATT_WAKEUP means that the
> configuration supports Remote Wakeup requests: The device can
> be set to issue a wakeup request if something interesting
> happens while it is suspended.
>
> (Note that the
On Fri, Sep 23, 2005 at 02:01:20AM -0700, Andrew Morton wrote:
>
>
> Begin forwarded message:
>
> Date: Fri, 23 Sep 2005 00:32:01 -0400
> From: Kurt Wall <[EMAIL PROTECTED]>
> To: linux-kernel@vger.kernel.org
> Subject: GPF Using Quickcam
>
>
> Evenin' all,
>
> I was testing out my spiffy new
On Fri, 23 Sep 2005, Conio sandiago wrote:
> Hi all
> I am porting the Linux EHCI usb driver for 2.6.9 kernel to 2.6.10 kernel
> During this i was facing following problems in compilation -
This may be a stupid question, but why do you need to port the EHCI driver
from 2.6.9 to 2.6.10? 2.6.10 a
On Fri, 23 Sep 2005, Oliver Neukum wrote:
> A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> irqsave. It will just be slower. But in a tasklet or interrupt handler
> spin_lock() will do. Basically these locks differ in whether they shut down
> irq processing on the local
Hello Alen
actually i am not porting the in built kernel ehci driver
i am porting the driver which is developed for my specific hardware,
so i am only defining two functions for my driver i.e.
ehci_hardware_probe and ehci_hardware_remove
i have registeded my driver in 2.6.10
but i m facing the pro
> > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > irqsave. It will just be slower. But in a tasklet or interrupt handler
> > spin_lock() will do. Basically these locks differ in whether they shut down
> > irq processing on the local CPU. In interrupt it is down and mu
On Fri, 23 Sep 2005, Conio sandiago wrote:
> Hello Alen
> actually i am not porting the in built kernel ehci driver
> i am porting the driver which is developed for my specific hardware,
> so i am only defining two functions for my driver i.e.
> ehci_hardware_probe and ehci_hardware_remove
If you
On Fri, 23 Sep 2005, Duncan Sands wrote:
> > This may depend on the particular architecture or platform. On x86,
> > general interrupts are not always disabled during interrupt handlers.
> > Only the particular IRQ line being handled.
>
> What's more, in the particular case of urb completion c
On Fri, 23 Sep 2005, Greg Lee wrote:
> Alan and David, thanks for the responses. The original output that I sent
> was generated by the show_usb_* functions in usb_debug.c. Here is the lsusb
> (ver 0.71) output for the non-working firmware. The lsusb output seems to
> be less thorough than the
On Fri, 23 Sep 2005, Chuck Ebbert wrote:
> OHCI is claiming my USB 2.0 hub, connected to the built-in USB port
> on my x86-64 notebook.
>
> This happens on both 2.6.13.2 and 2.6.14-rc2:
Didn't some notebooks like that end up having problems in their EHCI
controllers?
Alan Stern
> > What's more, in the particular case of urb completion callbacks there is
> > no guarantee that the callback is even called from an interrupt.
>
> Right, although there is a guarantee that local interrupts will be
> disabled when the completion handler is called. That guarantee may be
> remo
On Fri, 23 Sep 2005, Andy Chuo wrote:
> Hi alan,
> Ok here's the revised version:
> static void /*__exit or __init? */ __exit cleanup(void)
> {
> struct socle_lp2a_udc *dev = the_controller;
>
> if (!dev)
> return;
>
> udc_disable(dev);
> remove_proc_files()
Hello Alan,
i am really sorry for all the mess.
But thank you very much for giving the information.
Thanks
On 9/23/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Sep 2005, Oliver Neukum wrote:
>
> > A driver using spin_lock_irq() in a tasklet is buggy. You can always use
> > irqsave. It wi
Hello Greg ,
What kernel version would you recommend for porting usb-serial driver
for 2.4 ?
(Considering the stablity of usb/usb-serial layer in 2.4)
Thanks ,
Monali.
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 21, 2005 6:25 PM
> To: Mo
after:
echo shutdown > /sys/power/disk
echo disk > /sys/power/state
i get:
Could not suspend device :00:0a.2: error -22
:00:0a.0 USB Controller: VIA Technologies, Inc. VT82x UHCI
USB 1.1 Controller (rev 50)
:00:0a.1 USB Controller: VIA Technologies, Inc. VT82x UHCI
USB 1.
On Thu, 22 Sep 2005, David Brownell wrote:
> Here are a bunch of USB updates, many making power management
> become simpler, for 2.6.15.early merging. They go on top of
> 2.6.14-rc2 with the patches already in Greg's queue [1].
There are a few things in here I don't like.
>* PM updates for
On Fri, 23 Sep 2005, Patrizio Bassi wrote:
> after:
>
> echo shutdown > /sys/power/disk
> echo disk > /sys/power/state
>
> i get:
>
> Could not suspend device :00:0a.2: error -22
>
> :00:0a.0 USB Controller: VIA Technologies, Inc. VT82x UHCI
> USB 1.1 Controller (rev 50)
> > > (BTW, is there any possibility of changing things so that downstream
> > > devices really _are_ children of the hub interface instead of children of
> > > the hub device? This would have repercussions for userspace, since the
> > > sysfs pathnames would change -- which makes me suspect it's
> There are a few things in here I don't like.
>
> >* PM updates for usbcore. This is the stuff that simplifies
> > things by making CONFIG_USB_SUSPEND mean a lot less.
> >
> > - pm-root1.patch ... a handful of PM updates that don't
> > directly affect much else; e.g.
On Fri, 23 Sep 2005, David Brownell wrote:
> I sent by a proposal sketch a while ago that repurposed it as the
> manager for a set of devices. To suspend or resume a device X, the
> pmcore calls would replace x->bus->suspend(x) calls with something
> accessing a facet of some other object that kn
Alan Stern ha scritto:
On Fri, 23 Sep 2005, Patrizio Bassi wrote:
after:
echo shutdown > /sys/power/disk
echo disk > /sys/power/state
i get:
Could not suspend device :00:0a.2: error -22
:00:0a.0 USB Controller: VIA Technologies, Inc. VT82x UHCI
USB 1.1 Controller (rev 50)
0
On Fri, 23 Sep 2005, Patrizio Bassi wrote:
> >What happens if you rmmod ehci-hcd and leave uhci-hcd loaded?
> >
> >
> i wrote in the dmesg:
>
> eth1: Setting promiscuous mode.
> uhci_hcd :00:0a.1: HC isn't running!
> hub 3-0:1.0: PM: resume from 1, parent usb3 still 1
I can't tell from t
Alan Stern ha scritto:
On Fri, 23 Sep 2005, Patrizio Bassi wrote:
What happens if you rmmod ehci-hcd and leave uhci-hcd loaded?
i wrote in the dmesg:
eth1: Setting promiscuous mode.
uhci_hcd :00:0a.1: HC isn't running!
hub 3-0:1.0: PM: resume from 1, parent usb3 still 1
On Fri, 23 Sep 2005, David Brownell wrote:
> > Mostly in these, although maybe in a few of the others as well.
>
> Those are in fact the guts of the fixes, notably pm-root2.patch ...
Actually that was pretty much okay, except for this one question about
hub_resume. It was a big set of patches;
In-Reply-To: <[EMAIL PROTECTED]>
On Fri, 23 Sep 2005 at 11:05:39 -0700, David Brownell wrote:
> > OHCI is claiming my USB 2.0 hub, connected to the built-in USB port
> > on my x86-64 notebook.
>
> Or to say it more correctly: "ehci is NOT claiming it".
> If it's not doing that, there's some sor
Hi
How do I read the contents of ehci host controller capability registers and
operational registers using the driver ? I see that ehci-dbg.c has all the
necessary information to extract the register contents, however I do not
know how to make use of it.
Regards
Vivek
-Original Message-
On Fri, 23 Sep 2005, Chuck Ebbert wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
>
> On Fri, 23 Sep 2005 at 11:05:39 -0700, David Brownell wrote:
>
> > > OHCI is claiming my USB 2.0 hub, connected to the built-in USB port
> > > on my x86-64 notebook.
> >
> > Or to say it more correctly: "ehci is NO
I am using Fedora Core 4 x86_64 and a 2.6.13-based kernel (Fedora
development version 2.6.13-1.1570_FC5). I am working with the spca5xx
driver from http://mxhaard.free.fr/ to try and get my Logitech QuickCam
Chat camera to work. However I'm running into trouble because the driver
seems to be re
38 matches
Mail list logo