Ivan sent the original e-mail to linux-arm-kernel list, but
I think it is an usb issue and let's better discuss it on
USB list.
On Thu, 6 Oct 2005, Ivan Kalatchev wrote:
> We're using Viper board with two USB ports from Arcom for one of our
> applications. It has arm linux kernel 2.6.13-arcom2 and I've patched isp116x
> driver with isp116x-fix-2.6.13.bz2 (needed small change in viper.c also to
> comment out some fields in isp116x_platform_data structure). This board can
> be sent to sleep and then waken up on GPIO interrupt. I've tried to
> implement following scenario:
>
> 1. Memory stick is plugged into one of the ports and is mounted.
> 2. Board is sent to sleep, suspending USB
> 3. Board is waken up by GPIO interrupt
> 4. User wants to unmount memory stick and use different one.
Do you suspend the board via sysfs? If yes then by which
call exactly?
> Problem is that after board is waken up, USB controller is not resumed
> properly and doesn't react on changes in USB ports. Although if memory stick
> is still plugged in after waken up it can be accessed without problem.
Are you saying that after sleep you can still transfer data
to/from stick over its device node regardless of the failed
resume of the usb host controller.
> I compiled isp116x_hcd driver with verbose debugging and here is part of
> dmesg that I get on suspend/resume operation:
>
> /////////////////////////////
> Stopping tasks: ==================== <- board is sent to sleep
> 116x: SetPortFeature: <7>116x: USB_PORT_FEAT_SUSPEND
> 116x: isp116x_suspend: state 3, phase 2
> 116x: isp116x-hcd suspended
> 116x: isp116x_suspend: state 3, phase 1
> 116x: isp116x_suspend: state 3, phase 3
> 116x: isp116x-hcd suspended
> CPU0: D VIVT undefined 5 cache
> CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
> CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
> eth0: link down
The suspend half seems to be OK
> 116x: isp116x_resume: state 3, phase 0 <- board is waken up
> usb usb1: PM: resume from 3, parent isp116x-hcd still 3
> hub 1-0:1.0: PM: resume from 3, parent usb1 still 3
> hub 1-0:1.0: hub_port_status failed (err = -113)
> hub 1-0:1.0: hub_port_status failed (err = -113)
> hub 1-0:1.0: activate --> -113
> usb 1-2: PM: resume from 3, parent usb1 still 3
> hub 1-0:1.0: cannot disable port 2 (err = -113)
> 1-2:1.0: PM: resume from 0, parent 1-2 still 3
> hub 1-0:1.0: hub_port_status failed (err = -113)
> hub 1-0:1.0: hub_port_status failed (err = -113)
> Restarting tasks... done
> eth0: link up, 10Mbps, half-duplex, lpa 0x0021
> ///////////////////////////////////
>From this log it is clear that isp116x_resume() was called,
but inside it the call to
usb_resume_device(hcd->self.root_hub) returned nonzero,
i.e., bringing root hub out of suspend failed. Failure to
resume the children followed unavoidably then.
> I checked the value that is written into the control register HCCONTROL of the
> isp116x when sending board to sleep in isp116x_hub_suspend - it is 192,
> which is HCCONTROL_USB_SUSPEND , but when board is waken up, the value
> that driver reads from this register in isp116x_hub_resume is 0 and
> isp116x_hub_resume function always returns EBUSY and never actually
> resumes USB ports.
This EBUSY may explain, why call to usb_resume_device() in
isp116x_resume() failed. But the question is, who's writing
USBReset into the HCCONTROL register? Or, alternatively,
did the HC chip become reset by entering/exiting the sleep?
Can you add the following call:
isp116x_show_regs(isp116x);
to the beginning of the isp116x_hub_resume() function and
show the resulting output, please.
> Is this the case of the 'deep sleep', that is not yet implemented in the
> driver?
No.
Olav
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
