On Saturday 11 August 2007, Alan Stern wrote:
> On Fri, 10 Aug 2007, David Brownell wrote:
>
> > > The code in ohci-hcd isn't very sophisticated about
> > > checking for interference from the firmware. Maybe because there are
> > > so many different implementations of OHCI floating around, it'
On Fri, 10 Aug 2007, David Brownell wrote:
> > The code in ohci-hcd isn't very sophisticated about
> > checking for interference from the firmware. Maybe because there are
> > so many different implementations of OHCI floating around, it's hard
> > to know what approach will work on all of th
On Friday 10 August 2007, Alan Stern wrote:
> > When the OLPC comes up from suspend, a small bit of Open Firmware code
> > gets run, this writes 1 to HcCommandStatus, resetting the OHCI chip into
> > Suspend mode, then writes into HcRhDescriptorB and HcRhPortStatus*,
> > bringing up the power to th
On Fri, 10 Aug 2007, Zephaniah E. Hull wrote:
> > After you get up :-), check udev->state at the end of
> > usb_suspend_device(). It should be USB_STATE_SUSPENDED, and nothing
> > should change it until usb_resume_device() runs.
> >
> > Are you maybe seeing ohci_rh_resume() get called twice in
On Thu, Aug 09, 2007 at 02:56:08PM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > Urgh, I definitely need some sleep, yes, it's a &&.
>
> > Which, from the debugging statements from previous failed runs, we have
> > something odder.
> >
> > reset_resume == 0, udev-
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> Urgh, I definitely need some sleep, yes, it's a &&.
> Which, from the debugging statements from previous failed runs, we have
> something odder.
>
> reset_resume == 0, udev->state == USB_STATE_CONFIGURED.
>
> This is an even more bizarre state then
On Thu, Aug 09, 2007 at 01:00:09PM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > I'll try to keep this making sense, but I'm going to have to reply to
> > things slightly out of order.
>
> Thanks for the detailed reply.
>
> > On Thu, Aug 09, 2007 at 11:27:02AM -04
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> I'll try to keep this making sense, but I'm going to have to reply to
> things slightly out of order.
Thanks for the detailed reply.
> On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote:
> > On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> >
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> OHCI isn't coming back on the OLPC after resume.
>
> After a bit of testing, the problem seems to have come down to two points.
>
> The first is that ohci_pci_resume is not forcing the root hub to be resumed
> properly, that's a fairly trivial and o
> > You mean ohci->regs->control doesn't contain OHCI_USB_RESET in the
> > appropriate bits? What does it contain? And why?
>
> ohci->hc_control & OHCI_CTRL_HCFS == OHCI_USB_SUSPEND, and I honestly
> don't have the foggiest clue how or why it has that after coming back
> from the chip being pow
I'll try to keep this making sense, but I'm going to have to reply to
things slightly out of order.
On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > OHCI isn't coming back on the OLPC after resume.
> >
> > After a bit of testing, th
On Thursday 09 August 2007, Zephaniah E. Hull wrote:
> OHCI isn't coming back on the OLPC after resume.
>
> After a bit of testing, the problem seems to have come down to two points.
>
> The first is that ohci_pci_resume is not forcing the root hub to be resumed
> properly, that's a fairly trivia
OHCI isn't coming back on the OLPC after resume.
After a bit of testing, the problem seems to have come down to two points.
The first is that ohci_pci_resume is not forcing the root hub to be resumed
properly, that's a fairly trivial and obviously correct patch.
The second is trickier, ohci_rh_r
13 matches
Mail list logo
