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
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
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-
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
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;
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, 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:
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, 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
> 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.
> > > (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
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)
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
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.
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
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
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()
> > 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, 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
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, 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, 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
> > 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
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
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
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, 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: [email protected]
> Subject: GPF Using Quickcam
>
>
> Evenin' all,
>
> I was testing out my spiffy new
> 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
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
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_buff
Begin forwarded message:
Date: Fri, 23 Sep 2005 00:32:01 -0400
From: Kurt Wall <[EMAIL PROTECTED]>
To: [email protected]
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
> > 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
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
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
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
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.
---
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
38 matches
Mail list logo
