Antonio Ospite <ospite@xxxxxxxxxxxxxxxxx> writes: > On Thu, 22 Jul 2010 17:14:04 +0200 > Antonio Ospite <ospite@xxxxxxxxxxxxxxxxx> wrote: >> > Now, the interrupt "storm" could block the kernel. That would rather be an host >> > issue. Did you try to connect your phone to another computer ? >> > >> > I would ask for a last test : on the first line of function pxa_udc_probe(), >> > insert "return 0;". If kernel still stalls, the pxa27x-udc is not involved. >> > >> >> By inserting that "return 0;" the kernel goes on and I can complete >> booting. Too bad, pxa27x_udc has to be the culprit ... Okay, I have a new track. Would you apply the patch below and see if that improves your problem. This one should: - disable the pullup line (and thus no irq should be triggered) - if an early irq is triggered anyway, don't handle it if no gadget driver was subscribed
diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c index 85b0d89..d9195dc 100644 --- a/drivers/usb/gadget/pxa27x_udc.c +++ b/drivers/usb/gadget/pxa27x_udc.c @@ -2384,6 +2384,9 @@ static irqreturn_t pxa_udc_irq(int irq, void *_dev) dev_vdbg(udc->dev, "Interrupt, UDCISR0:0x%08x, UDCISR1:0x%08x, " "UDCCR:0x%08x\n", udcisr0, udcisr1, udccr); + if (!udc->driver) + return IRQ_HANDLED; + udcisr1_spec = udcisr1 & 0xf8000000; if (unlikely(udcisr1_spec & UDCISR1_IRSU)) irq_udc_suspend(udc); @@ -2506,6 +2509,7 @@ static int __init pxa_udc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, udc); udc_init_data(udc); pxa_eps_setup(udc); + dplus_pullup(udc, 0); /* irq setup after old hardware state is cleaned up */ retval = request_irq(udc->irq, pxa_udc_irq,
Cheers. -- Robert
