Re: [4.4-rc1 regression] pxa27x_udc and suspend/resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Robert Jarzmik <robert.jarzmik@xxxxxxx> writes:
> Felipe Balbi <balbi@xxxxxx> writes:
>
>> Hi,
>>
>> without any sort of logs it a bit difficult :-) Care to send some output
>> of the failure ? Are there any oopses or what exactly happens ?
>
> Ah well, the UDC is the only way to "speak" to the board (no UART), so
> I don't have any written feedback available. All I have are the logs
> displayed on the phone's screen in the framebuffer screen.

you can increase fbcon verbosity, right ? I guess that was
CONFIG_MESSAGE_LOGLEVEL_DEFAULT.

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 ?

> 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.

> --- 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.

> 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 ?

> that "ping mioa701" doesn't work anymore.

that's kind of expected considering pxa27x disabled the UDC and
disconnects from the bus on suspend:

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 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 :-)

cheers

-- 
balbi

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux