On Thu, 4 Aug 2005, Olav Kongas wrote:
> > Relying on Resume Detected interrupt won't suffice, because
> > when suspending just a root hub port like above, the chip
> > won't generate Resume Detected but just Status Change. So,
> > the only sources of information to decide about the
> > necess
On Thu, 4 Aug 2005, Olav Kongas wrote:
>
> On Wed, 3 Aug 2005, Alan Stern wrote:
> > I think the easiest solution will be for your HCD to test whether a delay
> > is needed. If not, go ahead and call usb_hcd_poll_rh_status as usual. If
> > a delay is needed, then do
>
> Relying on Resume De
On Thu, 4 Aug 2005, Olav Kongas wrote:
> > This delay would only apply when the HC is waking up from a sleep state,
> > right? So a lot of the time it won't be necessary...
>
> No. I haven't tested other configurations, but my corrent
> device tree is: rh-port -> external hub -> mouse. If I
>
On Wed, 3 Aug 2005, Alan Stern wrote:
> On Wed, 3 Aug 2005, Olav Kongas wrote:
>
> > Hi Alan,
> >
> > I started to look at the new polling scheme for root hub
> > status implemented by you in usb core recently.
> >
> > As the isp116x supports status change interrupts in both
> > running an
On Wed, 3 Aug 2005, Olav Kongas wrote:
> Hi Alan,
>
> I started to look at the new polling scheme for root hub
> status implemented by you in usb core recently.
>
> As the isp116x supports status change interrupts in both
> running and suspended states, I just had to set
> hcd->uses_new_poll
