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 :-(
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
