Hi, On Mon, May 14, 2012 at 07:06:25PM +0200, Cousson, Benoit wrote: > On 5/14/2012 2:47 PM, Felipe Balbi wrote: > >Hi, > > > >On Mon, May 14, 2012 at 03:29:21PM +0300, Felipe Balbi wrote: > >>On Mon, May 14, 2012 at 03:24:11PM +0300, Tomi Valkeinen wrote: > >>>On Mon, 2012-05-14 at 15:15 +0300, Felipe Balbi wrote: > >>> > >>>>looks like MUSB is probing before transceiver driver... could it be ? > >>>>Can you check transceiver has actually probed ? I guess panda's using > >>>>twl6030-usb.c > >>> > >>>Ah. Perhaps it's then about this? > >>> > >>>[ 0.352905] Skipping twl internal clock init and using bootloader value (unknown osc rate) > >>>[ 0.354034] twl 1-0048: PIH (irq 39) chaining IRQs 352..372 > >>>[ 0.356079] VUSB: 3300 mV normal standby > >>>[ 0.358123] genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 356 > >>>[ 0.358215] twl6030_usb twl6030_usb: can't get IRQ 356, err -22 > >>>[ 0.358398] twl6030_usb: probe of twl6030_usb failed with error -22 > >> > >>sounds about right. Now, why can't it get the IRQ... Benoit, is this > >>related to your sparse irq/irq_domain changes ? > > > >Looks like twl6030-irq still missed conversion to threaded IRQ. It still > >has that ugly ass kthread to handle the IRQs. Oh well, yet another > >broken OMAP driver... > > Well, yeah, I did not clean all that mess. > > That being said, we did have some issue recently as well, but due to > the increase of IRQ number and the fact the NR_IRQS is still used > since SPARSE_IRQ migration is not completed. > > At least we saw similar issue with OMAP5. > > Maybe increasing NR_IRQS will fix that, but in this case, it looks > like the IRQ might already been used by someone else. > This is probably because something is still using the hard coded IRQ > BASE number from the irqs.h define. > > I was planning to get rid of them to highlight the broken driver / > board that might still used them. But this is on my TODO list :-( another thing you might want to add to your TODO list is implementing irq_chip properly on twl6030-irq: $ git grep -e EXPORT_SYMBOL drivers/mfd/twl6030-irq.c drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask); drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask); drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect_config); drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_mmc_card_detect); $ git grep -e "twl6030_interrupt_\(mask\|unmask\)" drivers/ drivers/mfd/twl6030-irq.c:int twl6030_interrupt_unmask(u8 bit_mask, u8 offset) drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_unmask); drivers/mfd/twl6030-irq.c:int twl6030_interrupt_mask(u8 bit_mask, u8 offset) drivers/mfd/twl6030-irq.c:EXPORT_SYMBOL(twl6030_interrupt_mask); drivers/mfd/twl6030-irq.c: twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK, drivers/mfd/twl6030-irq.c: twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_mask(TWL6030_RTC_INT_MASK, drivers/rtc/rtc-twl.c: twl6030_interrupt_mask(TWL6030_RTC_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(0x05, REG_INT_MSK_LINE_C); drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(0x05, REG_INT_MSK_STS_C); drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK, drivers/usb/otg/twl6030-usb.c: twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK, That whole MMC card detection is also pretty screwed up. Balaji/Venkat, can you guys look into that ? Probably making something generic using a threaded IRQ handler ? I mean, all the MMC core should need is an IRQ number (through GPIOs or not doesn't/shouldn't matter) and it should be able to use a threaded IRQ handler to kick the card detection/initialization. -- balbi
Attachment:
signature.asc
Description: Digital signature
