Hi Felipe,
On 08.04.2014 16:31, Felipe Balbi wrote:
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>> index 819a7cd..d369bf1 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>>> @@ -316,7 +316,13 @@ static void omap_musb_mailbox_work(struct work_struct *mailbox_work)
>>> {
>>> struct omap2430_glue *glue = container_of(mailbox_work,
>>> struct omap2430_glue, omap_musb_mailbox_work);
>>> + struct musb *musb = glue_to_musb(glue);
>>> + struct device *dev = musb->controller;
>>> +
>>> + pm_runtime_get_sync(dev);
>>> omap_musb_set_mailbox(glue);
>>> + pm_runtime_mark_last_busy(dev);
>>> + pm_runtime_put_autosuspend(dev);
>>> }
>>>
>>> static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
>>>
>>> let me know
>>
>> The crash doesn't appear anymore with this patch. But the ethernet
>> gadget is not started. This happens also with a plugged cable upon
>> driver startup. Now I see an error in the log:
>>
>> [ 2.793121] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in b_idle (80, <SessEnd), retry #0, port1 00000100
>
> that shouldn't happen... Can you add some extra debugging prints and try
> to figure out what's going on ?
Unfortunately I can't reproduce this error. And the crash is also not
happening right now. Seems to be very timing sensitive.
Still with both patches applied, the ethernet gadget is only started
correctly (with cable connected after driver loading) when I add some
printk's. This one helps for example:
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
unsigned long flags;
u8 power;
u8 devctl;
#if 1 // test-only: this helps as well with gadget to connect
printk("*** %s (%d): state=%d\n", __func__, __LINE__, musb->xceiv->state); // test-only
#endif
Without this printk the gadget is not started upon cable insertion.
No MUSB interrupts occur when the USB cable is connected.
There seems to be some timing dependency which I fail to solve
quickly. The original locations (removed with [1]) for
phy_power_on() and phy_power_off() don't suffer these timing /
printk dependencies.
Any ideas?
Thanks,
Stefan
[1] 30a70b02 (usb: musb: fix obex in g_nokia.ko causing kernel panic)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
