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

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

[Daniel Ng2]

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

[Scott Wood]

On Mon, 18 Jul 2011 22:39:01 -0700
Daniel Ng2 <daniel.ng1234@gmail.com> 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