Felipe Balbi <balbi@xxxxxx> writes:
> Hi,
> you can increase fbcon verbosity, right ? I guess that was
> CONFIG_MESSAGE_LOGLEVEL_DEFAULT.
Sure.
> Set it to 9 and you should get everything. Another option is to change
> dev_* to dev_crit() and KERN_* to KERN_CRIT.
>
>> I know there is not panic/crash, as the screen show no stack/panic. I
>> also know that disconnecting and reconnecting the USB cable triggers
>> the logs of the phy vbus detection.
>
> does it reenumerate fine when you unplug and replug ?
Yeah, I think the log below on host side show this.
>> From what I see the kernel is perfectly resumed, ie. key inputs
>> trigger changes on the framebuffer.
>>
>> I have the host side logs :
>> 1035787.154247] usb 1-1: New USB device found, idVendor=049f, idProduct=505a
>> [1035787.154254] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>> [1035787.154257] usb 1-1: Product: Ethernet Gadget
>> [1035787.154259] usb 1-1: Manufacturer: Linux 4.4.0-rc1 with pxa27x_udc
>> [1035787.170423] cdc_subset 1-1:1.0 usb0: register 'cdc_subset' at usb-0000:00:14.0-1, Linux Device, 9a:7b:ac:1c:65:82
>> [1035822.149430] usb 1-1: USB disconnect, device number 69
>> [1035822.149564] cdc_subset 1-1:1.0 usb0: unregister 'cdc_subset'
>> usb-0000:00:14.0-1, Linux Device
>
> is pxa27x always full-speed ? Seems like it, but I see that max_speed is
> never set there. That's a bug, but a very minor one.
Yes, always full-speed, right. As for max_speed, I will look into it.
>> --- here the board is gone to "Suspend to RAM" ---
>>
>> [1035829.041922] usb 1-1: new full-speed USB device number 70 using xhci_hcd
>> [1035829.172194] usb 1-1: New USB device found, idVendor=049f, idProduct=505a
>> [1035829.172197] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>> [1035829.172199] usb 1-1: Product: Ethernet Gadget
>> [1035829.172200] usb 1-1: Manufacturer: Linux 4.4.0-rc1 with pxa27x_udc
>> [1035829.187640] cdc_subset 1-1:1.0 usb0: register 'cdc_subset' at usb-0000:00:14.0-1, Linux Device, 9a:7b:ac:1c:65:82
>
> so it actually connects again just fine, this means suspend/resume works
> as before.
>From host side, yes. From device side, it's a bit different, as you can see in
the other mail I sent : all the log containing "already enabled, doing nothing"
are in v4.3 (ie. in working case), and absent in v4.4-rc1 (ie. broken case).
>> Here the board is back from suspend to RAM. It "looks" as if either it
>> lost its IP setup, or something else ... the final effect "felt" is
>
> But you still have your usb0 interface, right ? Does that have an IP
> address when you look at ifconfig ?
Yes, just as before, on host side I see no difference. The interface reappears
and is IP configured automaticaly (my host PC setup takes care of that).
>> that "ping mioa701" doesn't work anymore.
>
> that's kind of expected considering pxa27x disabled the UDC and
> disconnects from the bus on suspend:
Euh it's expected to work _after resume_.
>
> static int pxa_udc_suspend(struct platform_device *_dev, pm_message_t state)
> {
> struct pxa_udc *udc = platform_get_drvdata(_dev);
> struct pxa_ep *ep;
>
> ep = &udc->pxa_ep[0];
> udc->udccsr0 = udc_ep_readl(ep, UDCCSR);
>
> udc_disable(udc);
> udc->pullup_resume = udc->pullup_on;
> dplus_pullup(udc, 0);
>
> return 0;
> }
>
> I'm actually surprised that it ever worked before :-)
I don't follow you : upon resume, ie. after pxa_udc_resume(), it worked
before. The case that bothers me is after resume, not between suspend() and
resume().
>> I can try that on another board (ie. with an UART, ie. a mainstone),
>> but I don't have a working setup for suspend/resume, so it will
>> probably take time.
> yeah, let's try to avoid that if possible :-)
Agreed.
Cheers.
--
Robert
--
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
