在 2021/10/12 上午12:17, Alan Stern 写道:
On Mon, Oct 11, 2021 at 01:10:18PM +0800, zhuyinbo wrote:
在 2021/10/10 上午3:39, Alan Stern 写道:
On Sat, Oct 09, 2021 at 10:01:25AM +0800, zhuyinbo wrote:
在 2021/10/8 下午10:26, Alan Stern 写道:
On Fri, Oct 08, 2021 at 03:26:10PM +0800, Yinbo Zhu wrote:
The usb states of ohci controller include UsbOperational, UsbReset,
UsbSuspend and UsbResume. Among them, only the UsbOperational state
supports launching the start of frame for host controller according
the ohci protocol spec, but in S3/S4 press test procedure, it may
Nobody reading this will know what "S3/S4 press test procedure" means.
You have to explain it, or use a different name that people will
understand.
okay, I got it.
happen that the start of frame was launched in other usb states and
cause ohci works abnormally then kernel will allways report rcu
call trace. This patch was to add check for host controller
functional states and if it is not UsbOperational state that need
set INTR_SF in intrdisable register to ensure SOF Token generation
was been disabled.
This doesn't make sense. You already mentioned that only the
UsbOperational state supports sending start-of-frame packets. So if the
controller is in a different state then it won't send these packets,
whether INTR_SF is enabled or not.
What problem are you really trying to solve?
Only UsbOperational state supports sending start-of-frame packets, but in
fact, in S3/S4 press test procedure,
usb in non-UsbOperational state that send start-of-frame packets but hc
driver doesn't deal with this frame. and hc will
allways lauched the SOF for finishing the frame, the cpu will hand this sof
interrupt and doesn't deal with time interrupt
that will cause rcu call trace then system doesn't suspend to memory/disk.
I still don't understand.
Are you saying that your OHCI controller behaves badly because it sends
SOF packets even when the state is different from UsbOperational?
HC will allways report the SoF interrupt in the all time when HC was not in
NO-UsbOperation state.
How did your host controller get into the non-UsbOperational state?
What part of the code is responsible for changing to a different state?
It looks like the only place where this could happen is in
ohci_rh_suspend(). So if you disable SOF interrupts there, it should
fix your problem.
in fact, I want to consider all non-UsbOperational state for my patch,
as for UsbSuspend state and my issue that
your advice is the pefect solution, and apply for the change according
to your advice, it can fix my problem by my test.
in addition, I got the non-UsbOperationnal state was by read hcfs bits
in ohci control register, for the UsbSuspend status that
it is only changed in ohci_rh_suspend. and other states was changed in
multiple place that seems disable sof interrupt was only
in ohci_irq. but if you still think it has risk i want to following
your advice and as it v5 version.
and no WritebackDoneHead interrupt that is the issue phenomenon. and this
situation is badly state for ohci.
Hi Alan Stern,
even though ed_rm_list is non-NULL, if hc in non-UsbOperation state set
SoF status in usbsts register that is illegal,
at this time hcd doesn't need care URB whether finished, because hc had
into a wrong state. even thoug it doesn't has this patch,
URB was not be able to finish when hc in above worng state. except software
can intervence this wrong state. but the SoF bit of usbsts
register was set by HC, and this action will happen always !!! software
clear SoF state I think it isn't make sense. software only disable SoF
interrupt to fix HC wrong state.
This problem happens when you go into S3 or S4 suspend, right? So you
should fix the problem by disabling INTR_SF when the root hub is
suspended. Try adding
/* All ED unlinks should be finished, no need for SOF interrupts */
ohci_writel(ohci, OHCI_INTR_SF, &ohci->regs->intrdisable);
into ohci_rh_suspend(), just before the update_done_list() call. If you
add this then INTR_SF will not be enabled during S3 or S4 suspend, so
the problem shouldn't occur. Does that work for you?
The system doesn't suspend to disk completely by my test result and hc will
always produce SoF interrupt.
Have you tried adding those two lines of code shown above?
If you haven't tested them, please don't write back until you have.
Alan Stern
Hi Alan stern,
I have a try that follow your advice and the s3/s4 test result is
good for me.
Thanks,
Yinbo Zhu.
