setbat() in udbg_init_cpm() required to avoid driver lockup

2 messages, 2 authors, 2011-07-19 · open the first message on its own page

setbat() in udbg_init_cpm() required to avoid driver lockup

From: Daniel Ng2 <hidden>
Date: 2011-07-19 05:39:03

Our USB Device Controller (UDC) driver seems to get stuck in a loop waiting
for the CPM Command Register to indicate that the CPM has finished executing
a command. (It should do this by setting the cpmcr 'Command Done' bit).

This only happens if I disable the 'Early Debug' Kernel Hacking .config
parameter. If Early Debug is enabled, then the problem goes away.

I've narrowed it down to this line in udbg_init_cpm(void):

setbat(1, 0xf0000000, 0xf0000000, 0x40000, PAGE_KERNEL_NCG);

-without this line, the driver gets stuck in the loop.

Can anyone suggest why?

Also, what undesireable effects might there be of keeping the above call to
setbat()?

System:
-MPC8272 (CPM2)
-Kernel 2.6.30.3

Cheers,
Daniel

-- 
View this message in context: http://old.nabble.com/setbat%28%29-in-udbg_init_cpm%28%29-required-to-avoid-driver-lockup-tp32088424p32088424.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: setbat() in udbg_init_cpm() required to avoid driver lockup

From: Scott Wood <hidden>
Date: 2011-07-19 18:24:38

On Mon, 18 Jul 2011 22:39:01 -0700
Daniel Ng2 [off-list ref] wrote:
Our USB Device Controller (UDC) driver seems to get stuck in a loop waiting
for the CPM Command Register to indicate that the CPM has finished executing
a command. (It should do this by setting the cpmcr 'Command Done' bit).

This only happens if I disable the 'Early Debug' Kernel Hacking .config
parameter. If Early Debug is enabled, then the problem goes away.

I've narrowed it down to this line in udbg_init_cpm(void):

setbat(1, 0xf0000000, 0xf0000000, 0x40000, PAGE_KERNEL_NCG);

-without this line, the driver gets stuck in the loop.

Can anyone suggest why?
Is your USB driver accessing effective addresses from 0xf0000000 to
0xf0040000?  It should be using ioremap().
Also, what undesireable effects might there be of keeping the above call to
setbat()?
It's squatting on a chunk of virtual address space without properly
reserving it.  This is bad enough for a debug hack (and should be fixed).
Don't extend it to normal operation -- especially not as a substitute for
understanding the root cause of your problem.

-Scott
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help