Just to say - that my first COMMIT (adding support fo ONDA MT828UP) was simply
wrong. There was a firmware update, but it didn't influence the thing, so I
simply mistaken. But now, with the latter commit fixing the thing, all works
fine.
I will be better to keep udev running :) .
References:
-
On Fri, Apr 04 2014, Alan Stern wrote:
No error messages about hung-up tasks 120 seconds later?
Sorry. I had forgotten to wait 2 minutes...
Here again the log with information about hung-up tasks.
--
Peter
[ 97.307415] PM: Syncing filesystems ... done.
[ 97.412888] PM:
Hi Michal,
On Thu, Apr 3, 2014 at 8:53 PM, Michal Simek mon...@monstr.eu wrote:
+struct xusb_udc {
+struct usb_gadget gadget;
+struct xusb_ep ep[8];
+struct usb_gadget_driver *driver;
+struct cmdbuf ch9cmd;
+u32 usb_state;
+u32 remote_wkp;
+unsigned int
The USB bus specification says that 255 devices can be connected to the
host, but that doesn't mean the xHCI host controller has all the
internal resources to support that.
To me that sounds like such xHCI HCs can not be considered USB compliant. :\
I would tend to agree Peter. It sounds
Is there a way to test the maximum data transfer speed of an embedded device?
I need to find the bottleneck of my system.
I am currently using an i.mx6 freescale with kernel 3.0.35 from NAND
which I can not update for several reasons. With gadgetfs I can
achieve a maximum of 15 MByte/s in High
Hi Felipe,
On 04.04.2014 17:35, Stefan Roese wrote:
I'm currently seeing a problem on an OMAP3530 based board (Technexion
TAO3530). Where the MUSB is configured as device/peripheral and the
ethernet
gadget is compiled into the kernel. This works without any problems
and usb0
is available
On Mon, 7 Apr 2014 tzi...@me.com wrote:
Is there a way to test the maximum data transfer speed of an embedded device?
I need to find the bottleneck of my system.
I am currently using an i.mx6 freescale with kernel 3.0.35 from NAND
which I can not update for several reasons. With gadgetfs I
On Mon, 7 Apr 2014, Peter Münster wrote:
On Fri, Apr 04 2014, Alan Stern wrote:
No error messages about hung-up tasks 120 seconds later?
Sorry. I had forgotten to wait 2 minutes...
Here again the log with information about hung-up tasks.
This looks a lot like what you got before.
On Wed, 2 Apr 2014, Hannes Reinecke wrote:
On 04/01/2014 11:28 PM, Alan Stern wrote:
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index
On Mon, Apr 07, 2014 at 01:21:10PM +0200, Stefan Roese wrote:
Hi Felipe,
On 04.04.2014 17:35, Stefan Roese wrote:
I'm currently seeing a problem on an OMAP3530 based board (Technexion
TAO3530). Where the MUSB is configured as device/peripheral and the
ethernet
gadget is compiled into
Hi,
On Mon, Apr 07, 2014 at 02:36:13PM +0530, sundeep subbaraya wrote:
+/**
+ * xudc_wrstatus - Sets up the usb device status stages.
+ * @udc: pointer to the usb device controller structure.
+ */
+static void xudc_wrstatus(struct xusb_udc *udc)
+{
+ u32 epcfgreg;
+
+
On 04/03/2014 07:32 PM, Johan Hovold wrote:
Hi Mathias and Benjamin,
Mathias, I understand you've got quite a lot on your plate with xhci at
the moment, but have you had a change to look at this issue yet? It's an
xhci-issue (possibly due to buggy hw) which seems related to the
non-superspeed
On Mon, Apr 07, 2014 at 09:04:41AM +, Amund Hov wrote:
The USB bus specification says that 255 devices can be connected to the
host, but that doesn't mean the xHCI host controller has all the
internal resources to support that.
To me that sounds like such xHCI HCs can not be
Hi all,
I am implementing a driver (currently libusb-based, but may change to
kernel-based eventually) for a USB standard class type that makes use of
endpoint stalling as a synchronization mechanism to recover after error
conditions between device and host (the reasons for needing it are a
On Mon, Apr 07, 2014 at 09:04:41AM +, Amund Hov wrote:
The USB bus specification says that 255 devices can be connected to the
host, but that doesn't mean the xHCI host controller has all the
internal resources to support that.
To me that sounds like such xHCI HCs can not be
On 04/05/2014 11:42 AM, Apelete Seketeli wrote:
Document the process of writing an musb glue layer by taking the
Ingenic JZ4740 glue layer as an example, as it seems more simple than
most glue layers due to the basic feature set of the JZ4740 USB device
controller.
Signed-off-by: Apelete
Hi,
On Mon, Apr 07, 2014 at 03:12:09PM -0700, Randy Dunlap wrote:
On 04/05/2014 11:42 AM, Apelete Seketeli wrote:
Document the process of writing an musb glue layer by taking the
Ingenic JZ4740 glue layer as an example, as it seems more simple than
most glue layers due to the basic feature
On Mon, Apr 07, 2014 at 10:55:36AM +0200, Enrico Mioso (@atlantide) wrote:
Just to say - that my first COMMIT (adding support fo ONDA MT828UP) was
simply wrong. There was a firmware update, but it didn't influence the
thing, so I simply mistaken. But now, with the latter commit fixing the
ffs_epfile_io() is called from userspace, while ffs_func_esp_disable() might
be called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile-ep would be removed by
ffs_func_esp_disable() during ffs_epfile_io() is referring this
ffs_epfile_io() is called from userspace, while ffs_func_esp_disable() might
be called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile-ep would be removed by
ffs_func_esp_disable() during ffs_epfile_io() is referring this
From: xiao jin jin.x...@intel.com
Date: Tue, 25 Mar 2014 15:54:36 +0800
Subject: [PATCH] cdc-acm: some enhancement on acm delayed write
We find two problems on acm tty write delayed mechanism.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm
On Mon, 7 Apr 2014, Greg KH wrote:
==Date: Mon, 7 Apr 2014 17:22:09 -0700
==From: Greg KH gre...@linuxfoundation.org
==To: Enrico Mioso (@atlantide) mrkiko...@gmail.com
==Cc: net...@vger.kernel.org, linux-usb@vger.kernel.org,
==Oliver Neukum oli...@neukum.org
==Subject: Re: Fault ammission
22 matches
Mail list logo
