On Tue, 11 Oct 2005, Ivan Kalatchev wrote:
> I've tested your new patch. Everything works just fine. Host controller is
> restarted and alive after board is resumed.
> The only tricky moment is if user forgot to unmount memory stick before
> sending board to sleep. Say it was mounted as /dev/sda
Ivan,
Can you please test, whether the following patch will make
the HC alive again after suspend-to-ram in your system. Note
that the patch won't try to keep the state, it just
reinitializes the controller.
Olav
--- linux-2.6.13-usb-resume0/drivers/usb/host/isp116x-hcd.c 2005-10-10
08:
On Fri, 7 Oct 2005, Alan Stern wrote:
> On Fri, 7 Oct 2005, Olav Kongas wrote:
>
> > The last reply from Ivan, given below, shows that his chip
> > is reset during suspend to mem. The resume fails as the
> > isp116x-hcd's resume() method has currently no support to
> > handle the reset chip.
On Fri, 7 Oct 2005, Olav Kongas wrote:
> The last reply from Ivan, given below, shows that his chip
> is reset during suspend to mem. The resume fails as the
> isp116x-hcd's resume() method has currently no support to
> handle the reset chip.
>
> I went thru the docs in kernel's Documentation/
The last reply from Ivan, given below, shows that his chip
is reset during suspend to mem. The resume fails as the
isp116x-hcd's resume() method has currently no support to
handle the reset chip.
I went thru the docs in kernel's Documentation/power/ and
understood that for supporting suspend
On Fri, 7 Oct 2005, Olav Kongas wrote:
> 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
This looks suspicious right here. After isp116x_resume returns, the
power state for t
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
