From: Bjørn Mork
Date: Wed, 18 Jun 2014 14:21:24 +0200
> Messages from the modem exceeding 256 bytes cause communication
> failure.
>
> The WDM protocol is strictly "read on demand", meaning that we only
> poll for unread data after receiving a notification from the modem.
> Since we have no way
From: "Wang, Yu"
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.
2, Trying to suspend all devices.
2.1, If pci device under RPM suspended state, then pci driver will try
to resume it to RPM active state in prepare stage.
2.2, xhci_resume function will cal
On Wed, May 21, 2014 at 09:04:16AM +0800, Peter Chen wrote:
> Hi Felipe,
>
> This patch set cleans up unnecessary .unbind calling at udc driver,
> the udc core covers gadget driver's .unbind calling well.
>
> Peter Chen (5):
> usb: gadget: fsl_udc_core: should not call gadget driver's .unbind
>
On Sun, May 18, 2014 at 03:19:01PM +0800, Peter Chen wrote:
> The probe function may be probed deferal and called after .init
> section has freed.
>
> Peter Chen (6):
> usb: gadget: atmel_usba_udc: delete __init marker for probe
> usb: gadget: fsl_udc_core: delete __init marker for probe
> u
On Fri, 20 Jun 2014, Dennis New wrote:
> > With the new patch, mplayer is able to close gracefully, with pcm
> > errors like "No such device". This time, my dmesg was slightly
> > different, with an "HcDoneHead" message:
> >
> > [139650.866080] ohci-pci :00:13.0: HcDoneHead not written back;
On Sat, 21 Jun 2014, Pedro Erencia wrote:
> Hi,
>
> We are developing an ecg (electrocardiogram) application on an OMAP3
> device (DM3730 ti).
>
> An acquisition board gets the samples in microseconds and sends them
> to the OMAP board via USB.
>
> This acquisition board does a 16KHz sampling w
Hi,
We are developing an ecg (electrocardiogram) application on an OMAP3
device (DM3730 ti).
An acquisition board gets the samples in microseconds and sends them
to the OMAP board via USB.
This acquisition board does a 16KHz sampling which results in ~4000
bytes sent every 8ms to the OMAP board;
Here are the kernel messages leading to the hard lockup:
Jun 20 19:26:41 MINDBENDER kernel: scsi 9:0:0:0: uas_eh_device_reset_handler
Jun 20 19:26:41 MINDBENDER kernel: scsi host9: uas_eh_task_mgmt: LOGICAL UNIT
RESET:
Jun 20 19:26:41 MINDBENDER kernel: scsi host9: uas_eh_bus_reset_handler start
