Re: Kernel / USB bug
Am Dienstag, den 02.05.2017, 20:06 +0200 schrieb Nicolas Repentin: > Hi > > I got this bug : using last kernel on Archlinux (4.10.13-1, since 4.4), > an USB 3.0 external HDD dies all the time when writing on it. Hi, did 4.4 use uas? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: serial: ftdi_sio: fix setting latency for unprivileged users
On Tue, May 02, 2017 at 07:17:01PM +0200, Anthony Mallet wrote:
> Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> flag") enables unprivileged users to set the FTDI latency timer,
> but there was a logic flaw that skipped sending the corresponding
> USB control message to the device.
>
> Signed-off-by: Anthony Mallet
>
> ---
>
> Here is the patch, feel free to update the message and/or replace the
> Signed-off-by if you like.
Thanks, this looks really good, apart from one little thing: patches
should be based in the root kernel source directory, not in any lower
subdirectory (as mentioned in the process document).
git-format-patch is also a very convenient way to get the job done (see
also git-send-email).
I could fix this up if you prefer, but I suggest you respin the patch as
a v2 (remember to add v2 inside the "[PATCH v2]" prefix and add a short
changelog below the cut-off line) so that you've mastered the full
process for next time.
What do you say?
> --- drivers/usb/serial/ftdi_sio.c~2017-04-28 11:20:30.339227000 +0200
> +++ drivers/usb/serial/ftdi_sio.c 2017-04-28 11:20:52.647773000 +0200
So there should have been a directory before drivers in the above paths;
that's all that's missing.
There's a tool scripts/checkpatch.pl which you can run on a patch to
check for some common mistakes and which would have caught this one.
> @@ -1505,9 +1505,9 @@ static int set_serial_info(struct tty_st
> (new_serial.flags & ASYNC_FLAGS));
> priv->custom_divisor = new_serial.custom_divisor;
>
> +check_and_exit:
> write_latency_timer(port);
>
> -check_and_exit:
> if ((old_priv.flags & ASYNC_SPD_MASK) !=
>(priv->flags & ASYNC_SPD_MASK)) {
> if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: serial: option: add Telit ME910 support
This patch adds support for Telit ME910 PID 0x1100. Signed-off-by: Daniele Palmas --- 0x1100 composition is: tty + qdss + tty + rmnet Following lsusb output: Bus 003 Device 018: ID 1bc7:1100 Telit Wireless Solutions Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1bc7 Telit Wireless Solutions idProduct 0x1100 bcdDevice0.00 iManufacturer 3 Telit iProduct2 Telit ME910 iSerial 4 1f5fec bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 108 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 1 Telit Configuration bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttribut
RE: [PATCH] Fix for new version of realtek r8153
jake Briggs [mailto:nexus...@gmail.com] > Sent: Wednesday, May 03, 2017 7:21 AM [...] > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index 07f788c49d57..2a55459fdfac 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c > @@ -4277,6 +4277,7 @@ static void r8152b_get_version(struct r8152 *tp) > tp->mii.supports_gmii = 1; > break; > case 0x5c30: > + case 0x6010: The two chips are different. I don't think it is a good idea. Maybe you could use the driver from the Realtek website first. > tp->version = RTL_VER_06; > tp->mii.supports_gmii = 1; > break; -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chipidea USB controller hangs in peripheral mode under high memory bus pressure
Hi Peter,
Thank you for your quick reply.
On Wednesday 03 May 2017 11:10:55 Peter Chen wrote:
> On Tue, May 02, 2017 at 03:07:03PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > I ran into an issue with a Xilinx Zynq XC7Z010 system. The system acts as
> > a USB peripheral, using the UVC gadget driver.
> >
> > When transferring high bandwidth data over USB in isochronous mode,
> > complete system freezes are occasionally noticed. The problem was traced
> > to the following code from _hardware_enqueue() in
> > drivers/usb/chipidea/udc.c.
> >
> > wmb();
> > if (hw_read(ci, OP_ENDPTPRIME, BIT(n)))
> > goto done;
> > do {
> > hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
> > tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
> > } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
> > hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
> > if (tmp_stat)
> > goto done;
> >
> > The do ... while loop loops forever, and as the function is called under a
> > spin_lock_irqsave(), the system doesn't appreciate. Adding a maximum
> > number of iterations to exit the loop is easy (I'll try to submit a patch
> > after finding the root cause of the problem). That fixes the system hang,
> > but USB transfers are still broken.
> >
> > I've checked the code and unfortunately it seems to match the procedure
> > documented in the datasheet :-/
> >
> > The MTBF is several hours, but running 'memtester -M100'
> > (http://pyropus.ca/software/memtester/) in parallel to UVC video transfer
> > over USB brings the MTBF to a few minutes. The problem thus seems to be
> > related to memory bus pressure.
> >
> > Has anyone run into this problem before ? Is this a known issue ? I don't
> > mind getting my hands dirty debugging, but as I'm not familiar with the
> > chipidea USB controller pointers to what I should check in priority would
> > be appreciated.
>
> There was no one reported this problem before, but from the description,
> it seems an IC issue which is triggered at high loading memory bus,
> controller may not get time to visit memory at limited time.
That's my guess too. I was expecting the USB controller's bus master interface
to get stalled but eventually perform the access (or retry it, I'm not sure
what kind of bus it sits on), but there might be a hardware bug that messes up
the controller's state machine. I won't rule out the possibility of a software
issue yet, it might be possible to detect this condition and retry the
transfer.
> At Xilinx Zynq, its tx buffer is small, and less than 512 bytes
> (84bc70f94d81, "usb: chipidea: add xilinx zynq platform data"), and your
> throughput may be > (512 * 3) bytes/SoF, you can't use non-stream mode by
> reducing max packet size.
My throughput is actually 1*1024 bytes / SOF.
> I think you may observe many under-run at bus analyzer during the test.
I'll try to get this checked (as I don't have a USB analyzer here).
> As a workaround, you may try to do below things:
>
> 1. Link more TDs before the UVC run
Do you mean I should have more requests queued to avoid hitting the
software/hardware race that the loop handles ?
> 2. Comment out the code, you are stuck in, it is only useful for protect
> last td status which is handling or will be handled soon by hardware.
>
> /*
> do {
> hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
> tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
> } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
> hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
> if (tmp_stat)
> goto done;
> */
I'm not familiar with this driver, but if I understand things correctly, the
code (and the "TD tripwire" hardware feature) is here to handle a race
condition where the hardware could look at the last TD's next pointer at the
same time it gets updated by the software. If I comment the code out, won't
the endpoint will be primed unconditionally, even if it's currently executing
transfers ? Won't that be a problem ?
> 3. If it can let your test run more time, try change code like below:
>
> if (remaining_td_num > 2)
> don't do hardware check;
> else
> do hardware check.
I'll test that, but I assume I'm hitting the problem when the number of
remaining TDs is exactly one.
> Besides, I can try your test if you could show me the detail test steps.
I need to create an easy test case, at the moment it's a complex application
and not every part of it can be published. I'll try to provide an open-source
test case implementation.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] usb: musb: tusb6010_omap: Convert to DMAengine
Hi, With port_window support implemented in DMAengine and the sDMA DMAengine driver, the tusb6010_omap driver can be converted away from the custom legacy omap-dma API to generic DMAengine. The first two patch is to prepare the tusb6010_omap driver for the conversion. The third one adds the needed entries for the dma_slave_map so we can request the DMA channels. This can be reverted when the stack is converted to DT. The last patch does the main work to move the driver to DMAengine API. I have tested the set on top of next-20170503 on Nokia n810 with nfsroot using CDC Ethernet (g_cdc) and copying files with scp to/form my host. To force that the DMA is actually used I have: diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c index 05aefcad40b5..a5fc2a6bdad3 100644 --- a/drivers/usb/musb/tusb6010_omap.c +++ b/drivers/usb/musb/tusb6010_omap.c @@ -216,8 +216,8 @@ static int tusb_omap_dma_program(struct dma_channel *channel, u16 packet_sz, * use a timer for the callback, but it is unsafe as the XFR_SIZE * register is corrupt, and we won't know if the DMA worked. */ - if (dma_addr & 0x2) - return false; +// if (dma_addr & 0x2) +// return false; /* * Because of HW issue #10, it seems like mixing sync DMA and async Since this condition will almost all the time was true - effectively disabling the DMA use. Regards. Peter --- Peter Ujfalusi (4): usb: musb: tusb6010_omap: Create new struct for DMA data/parameters usb: musb: tusb6010_omap: Allocate DMA channels upfront ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines usb: musb: tusb6010_omap: Convert to dmaengine WIP arch/arm/mach-omap2/dma.c| 24 +++ drivers/usb/musb/tusb6010_omap.c | 342 ++- 2 files changed, 177 insertions(+), 189 deletions(-) -- 2.12.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: musb: tusb6010_omap: Create new struct for DMA data/parameters
For the DMA we have ch (channel), dmareq and sync_dev parameters both
within the tusb_omap_dma_ch and tusb_omap_dma_ch struct.
By creating a common struct the code can be simplified when selecting
between the shared or multichannel DMA parameters.
Signed-off-by: Peter Ujfalusi
---
drivers/usb/musb/tusb6010_omap.c | 163 ---
1 file changed, 84 insertions(+), 79 deletions(-)
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 8b43c4b99f04..2abd7895c3af 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -31,6 +31,12 @@
#define OMAP242X_DMA_EXT_DMAREQ4 16
#define OMAP242X_DMA_EXT_DMAREQ5 64
+struct tusb_dma_data {
+ int ch;
+ s8 dmareq;
+ s8 sync_dev;
+};
+
struct tusb_omap_dma_ch {
struct musb *musb;
void __iomem*tbase;
@@ -39,9 +45,7 @@ struct tusb_omap_dma_ch {
u8 tx;
struct musb_hw_ep *hw_ep;
- int ch;
- s8 dmareq;
- s8 sync_dev;
+ struct tusb_dma_datadma_data;
struct tusb_omap_dma*tusb_dma;
@@ -58,9 +62,7 @@ struct tusb_omap_dma {
struct dma_controller controller;
void __iomem*tbase;
- int ch;
- s8 dmareq;
- s8 sync_dev;
+ struct tusb_dma_datadma_data;
unsignedmultichannel:1;
};
@@ -119,9 +121,9 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void
*data)
spin_lock_irqsave(&musb->lock, flags);
if (tusb_dma->multichannel)
- ch = chdat->ch;
+ ch = chdat->dma_data.ch;
else
- ch = tusb_dma->ch;
+ ch = tusb_dma->dma_data.ch;
if (ch_status != OMAP_DMA_BLOCK_IRQ)
printk(KERN_ERR "TUSB DMA error status: %i\n", ch_status);
@@ -140,8 +142,7 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void
*data)
/* HW issue #10: XFR_SIZE may get corrupt on DMA (both async & sync) */
if (unlikely(remaining > chdat->transfer_len)) {
dev_dbg(musb->controller, "Corrupt %s dma ch%i XFR_SIZE:
0x%08lx\n",
- chdat->tx ? "tx" : "rx", chdat->ch,
- remaining);
+ chdat->tx ? "tx" : "rx", ch, remaining);
remaining = 0;
}
@@ -219,9 +220,7 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
u32 dma_remaining;
int src_burst, dst_burst;
u16 csr;
- int ch;
- s8 dmareq;
- s8 sync_dev;
+ struct tusb_dma_data*dma_data;
if (unlikely(dma_addr & 0x1) || (len < 32) || (len > packet_sz))
return false;
@@ -248,7 +247,7 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
dma_remaining = TUSB_EP_CONFIG_XFR_SIZE(dma_remaining);
if (dma_remaining) {
dev_dbg(musb->controller, "Busy %s dma ch%i, not using: %08x\n",
- chdat->tx ? "tx" : "rx", chdat->ch,
+ chdat->tx ? "tx" : "rx", chdat->dma_data.ch,
dma_remaining);
return false;
}
@@ -261,15 +260,15 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
chdat->transfer_packet_sz = packet_sz;
if (tusb_dma->multichannel) {
- ch = chdat->ch;
- dmareq = chdat->dmareq;
- sync_dev = chdat->sync_dev;
+ dma_data = &chdat->dma_data;
} else {
+ dma_data = &tusb_dma->dma_data;
+
if (tusb_omap_use_shared_dmareq(chdat) != 0) {
dev_dbg(musb->controller, "could not get dma for
ep%i\n", chdat->epnum);
return false;
}
- if (tusb_dma->ch < 0) {
+ if (dma_data->ch < 0) {
/* REVISIT: This should get blocked earlier, happens
* with MSC ErrorRecoveryTest
*/
@@ -277,10 +276,7 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
return false;
}
- ch = tusb_dma->ch;
- dmareq = tusb_dma->dmareq;
- sync_dev = tusb_dma->sync_dev;
- omap_set_dma_callback(ch, tusb_omap_dma_cb, channel);
+ omap_set_dma_callback(dma_data->ch, tusb
[PATCH 2/4] usb: musb: tusb6010_omap: Allocate DMA channels upfront
Instead of requesting the DMA channel in tusb_omap_dma_allocate() do it
when the controller is created and in runtime work from the DMA channel
pool.
This change is needed for the DMAengine conversion of the driver since the
tusb_omap_dma_allocate() is called in interrupt context which might lead
to lock within the DMAengine API when requesting channel.
Signed-off-by: Peter Ujfalusi
---
drivers/usb/musb/tusb6010_omap.c | 184 +++
1 file changed, 92 insertions(+), 92 deletions(-)
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 2abd7895c3af..244b7b7cd26a 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -45,7 +45,7 @@ struct tusb_omap_dma_ch {
u8 tx;
struct musb_hw_ep *hw_ep;
- struct tusb_dma_datadma_data;
+ struct tusb_dma_data*dma_data;
struct tusb_omap_dma*tusb_dma;
@@ -62,7 +62,7 @@ struct tusb_omap_dma {
struct dma_controller controller;
void __iomem*tbase;
- struct tusb_dma_datadma_data;
+ struct tusb_dma_datadma_pool[MAX_DMAREQ];
unsignedmultichannel:1;
};
@@ -120,10 +120,7 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void
*data)
spin_lock_irqsave(&musb->lock, flags);
- if (tusb_dma->multichannel)
- ch = chdat->dma_data.ch;
- else
- ch = tusb_dma->dma_data.ch;
+ ch = chdat->dma_data->ch;
if (ch_status != OMAP_DMA_BLOCK_IRQ)
printk(KERN_ERR "TUSB DMA error status: %i\n", ch_status);
@@ -247,7 +244,8 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
dma_remaining = TUSB_EP_CONFIG_XFR_SIZE(dma_remaining);
if (dma_remaining) {
dev_dbg(musb->controller, "Busy %s dma ch%i, not using: %08x\n",
- chdat->tx ? "tx" : "rx", chdat->dma_data.ch,
+ chdat->tx ? "tx" : "rx",
+ chdat->dma_data ? chdat->dma_data->ch : -1,
dma_remaining);
return false;
}
@@ -259,11 +257,8 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
else
chdat->transfer_packet_sz = packet_sz;
- if (tusb_dma->multichannel) {
- dma_data = &chdat->dma_data;
- } else {
- dma_data = &tusb_dma->dma_data;
-
+ dma_data = chdat->dma_data;
+ if (!tusb_dma->multichannel) {
if (tusb_omap_use_shared_dmareq(chdat) != 0) {
dev_dbg(musb->controller, "could not get dma for
ep%i\n", chdat->epnum);
return false;
@@ -275,10 +270,10 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
WARN_ON(1);
return false;
}
-
- omap_set_dma_callback(dma_data->ch, tusb_omap_dma_cb, channel);
}
+ omap_set_dma_callback(dma_data->ch, tusb_omap_dma_cb, channel);
+
chdat->packet_sz = packet_sz;
chdat->len = len;
channel->actual_len = 0;
@@ -406,19 +401,9 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
static int tusb_omap_dma_abort(struct dma_channel *channel)
{
struct tusb_omap_dma_ch *chdat = to_chdat(channel);
- struct tusb_omap_dma*tusb_dma = chdat->tusb_dma;
- struct tusb_dma_data*dma_data = &tusb_dma->dma_data;
- if (!tusb_dma->multichannel) {
- if (dma_data->ch >= 0) {
- omap_stop_dma(dma_data->ch);
- omap_free_dma(dma_data->ch);
- dma_data->ch = -1;
- }
-
- dma_data->dmareq = -1;
- dma_data->sync_dev = -1;
- }
+ if (chdat->dma_data)
+ omap_stop_dma(chdat->dma_data->ch);
channel->status = MUSB_DMA_STATUS_FREE;
@@ -430,15 +415,6 @@ static inline int tusb_omap_dma_allocate_dmareq(struct
tusb_omap_dma_ch *chdat)
u32 reg = musb_readl(chdat->tbase, TUSB_DMA_EP_MAP);
int i, dmareq_nr = -1;
- const int sync_dev[6] = {
- OMAP24XX_DMA_EXT_DMAREQ0,
- OMAP24XX_DMA_EXT_DMAREQ1,
- OMAP242X_DMA_EXT_DMAREQ2,
- OMAP242X_DMA_EXT_DMAREQ3,
- OMAP242X_DMA_EXT_DMAREQ4,
- OMAP242X_DMA_EXT_DMAREQ5,
- };
-
for (i = 0; i < MAX_DMAREQ; i++) {
int cur = (reg & (0xf << (i * 5))) >> (i * 5);
if (cur == 0) {
@@ -455,8 +431,7 @@ static inline int tusb_omap_dma_allocate_dmareq(struct
tusb_omap_dma_ch *chdat)
reg |= ((1 << 4) << (dmareq_nr * 5));
musb_writel(chdat->tbase, TUSB_DMA_EP_MAP, re
[PATCH 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API
With the port_window support in DMAengine and the sDMA driver we can
convert the driver to DMAengine.
Signed-off-by: Peter Ujfalusi
---
drivers/usb/musb/tusb6010_omap.c | 201 ---
1 file changed, 80 insertions(+), 121 deletions(-)
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 244b7b7cd26a..05aefcad40b5 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include
+#include
#include "musb_core.h"
#include "tusb6010.h"
@@ -24,17 +24,9 @@
#define MAX_DMAREQ 5 /* REVISIT: Really 6, but req5 not OK */
-#define OMAP24XX_DMA_EXT_DMAREQ0 2
-#define OMAP24XX_DMA_EXT_DMAREQ1 3
-#define OMAP242X_DMA_EXT_DMAREQ2 14
-#define OMAP242X_DMA_EXT_DMAREQ3 15
-#define OMAP242X_DMA_EXT_DMAREQ4 16
-#define OMAP242X_DMA_EXT_DMAREQ5 64
-
struct tusb_dma_data {
- int ch;
s8 dmareq;
- s8 sync_dev;
+ struct dma_chan *chan;
};
struct tusb_omap_dma_ch {
@@ -105,7 +97,7 @@ static inline void tusb_omap_free_shared_dmareq(struct
tusb_omap_dma_ch *chdat)
* See also musb_dma_completion in plat_uds.c and musb_g_[tx|rx]() in
* musb_gadget.c.
*/
-static void tusb_omap_dma_cb(int lch, u16 ch_status, void *data)
+static void tusb_omap_dma_cb(void *data)
{
struct dma_channel *channel = (struct dma_channel *)data;
struct tusb_omap_dma_ch *chdat = to_chdat(channel);
@@ -116,18 +108,11 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void
*data)
void __iomem*ep_conf = hw_ep->conf;
void __iomem*mbase = musb->mregs;
unsigned long remaining, flags, pio;
- int ch;
spin_lock_irqsave(&musb->lock, flags);
- ch = chdat->dma_data->ch;
-
- if (ch_status != OMAP_DMA_BLOCK_IRQ)
- printk(KERN_ERR "TUSB DMA error status: %i\n", ch_status);
-
- dev_dbg(musb->controller, "ep%i %s dma callback ch: %i status: %x\n",
- chdat->epnum, chdat->tx ? "tx" : "rx",
- ch, ch_status);
+ dev_dbg(musb->controller, "ep%i %s dma callback\n",
+ chdat->epnum, chdat->tx ? "tx" : "rx");
if (chdat->tx)
remaining = musb_readl(ep_conf, TUSB_EP_TX_OFFSET);
@@ -138,8 +123,8 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void
*data)
/* HW issue #10: XFR_SIZE may get corrupt on DMA (both async & sync) */
if (unlikely(remaining > chdat->transfer_len)) {
- dev_dbg(musb->controller, "Corrupt %s dma ch%i XFR_SIZE:
0x%08lx\n",
- chdat->tx ? "tx" : "rx", ch, remaining);
+ dev_dbg(musb->controller, "Corrupt %s XFR_SIZE: 0x%08lx\n",
+ chdat->tx ? "tx" : "rx", remaining);
remaining = 0;
}
@@ -212,12 +197,15 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
struct musb_hw_ep *hw_ep = chdat->hw_ep;
void __iomem*mbase = musb->mregs;
void __iomem*ep_conf = hw_ep->conf;
- dma_addr_t fifo = hw_ep->fifo_sync;
- struct omap_dma_channel_params dma_params;
+ dma_addr_t fifo_addr = hw_ep->fifo_sync;
u32 dma_remaining;
- int src_burst, dst_burst;
u16 csr;
struct tusb_dma_data*dma_data;
+ struct dma_async_tx_descriptor *dma_desc;
+ struct dma_slave_config dma_cfg;
+ enum dma_transfer_direction dma_dir;
+ u32 port_window;
+ int ret;
if (unlikely(dma_addr & 0x1) || (len < 32) || (len > packet_sz))
return false;
@@ -243,10 +231,8 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
dma_remaining = TUSB_EP_CONFIG_XFR_SIZE(dma_remaining);
if (dma_remaining) {
- dev_dbg(musb->controller, "Busy %s dma ch%i, not using: %08x\n",
- chdat->tx ? "tx" : "rx",
- chdat->dma_data ? chdat->dma_data->ch : -1,
- dma_remaining);
+ dev_dbg(musb->controller, "Busy %s dma, not using: %08x\n",
+ chdat->tx ? "tx" : "rx", dma_remaining);
return false;
}
@@ -263,7 +249,7 @@ static int tusb_omap_dma_program(struct dma_channel
*channel, u16 packet_sz,
dev_dbg(musb->controller, "could not get dma for
ep%i\n", chdat->epnum);
return false;
}
- if (dma_data->ch < 0) {
+ if
[PATCH 0/4] usb: musb: tusb6010_omap: Convert to DMAengine
Hi, With port_window support implemented in DMAengine and the sDMA DMAengine driver, the tusb6010_omap driver can be converted away from the custom legacy omap-dma API to generic DMAengine. The first two patch is to prepare the tusb6010_omap driver for the conversion. The third one adds the needed entries for the dma_slave_map so we can request the DMA channels. This can be reverted when the stack is converted to DT. The last patch does the main work to move the driver to DMAengine API. I have tested the set on top of next-20170503 on Nokia n810 with nfsroot using CDC Ethernet (g_cdc) and copying files with scp to/form my host. To force that the DMA is actually used I have: diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c index 05aefcad40b5..a5fc2a6bdad3 100644 --- a/drivers/usb/musb/tusb6010_omap.c +++ b/drivers/usb/musb/tusb6010_omap.c @@ -216,8 +216,8 @@ static int tusb_omap_dma_program(struct dma_channel *channel, u16 packet_sz, * use a timer for the callback, but it is unsafe as the XFR_SIZE * register is corrupt, and we won't know if the DMA worked. */ - if (dma_addr & 0x2) - return false; +// if (dma_addr & 0x2) +// return false; /* * Because of HW issue #10, it seems like mixing sync DMA and async Since this condition will almost all the time was true - effectively disabling the DMA use. Regards. Peter --- Peter Ujfalusi (4): usb: musb: tusb6010_omap: Create new struct for DMA data/parameters usb: musb: tusb6010_omap: Allocate DMA channels upfront ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines usb: musb: tusb6010_omap: Convert to DMAengine API arch/arm/mach-omap2/dma.c| 24 +++ drivers/usb/musb/tusb6010_omap.c | 342 ++- 2 files changed, 177 insertions(+), 189 deletions(-) -- 2.12.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines
The external request lines are used by tusb6010 on OMAP24xx platforms.
Update the map so the driver can use dmaengine API to request the DMA
channel. At the same time add temporary map containing only the external
DMA request numbers for DT booted case on omap24xx since the tusb6010 stack
is not yet supports DT boot.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/dma.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index e58c13a9bea5..0b77a0176018 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -249,6 +249,24 @@ static const struct dma_slave_map omap24xx_sdma_map[] = {
{ "omap_uart.2", "rx", SDMA_FILTER_PARAM(54) },
{ "omap_hsmmc.0", "tx", SDMA_FILTER_PARAM(61) },
{ "omap_hsmmc.0", "rx", SDMA_FILTER_PARAM(62) },
+
+ /* external DMA requests when tusb6010 is used */
+ { "musb-tusb", "dmareq0", SDMA_FILTER_PARAM(2) },
+ { "musb-tusb", "dmareq1", SDMA_FILTER_PARAM(3) },
+ { "musb-tusb", "dmareq2", SDMA_FILTER_PARAM(14) }, /* OMAP2420 only */
+ { "musb-tusb", "dmareq3", SDMA_FILTER_PARAM(15) }, /* OMAP2420 only */
+ { "musb-tusb", "dmareq4", SDMA_FILTER_PARAM(16) }, /* OMAP2420 only */
+ { "musb-tusb", "dmareq5", SDMA_FILTER_PARAM(64) }, /* OMAP2420 only */
+};
+
+static const struct dma_slave_map omap24xx_sdma_dt_map[] = {
+ /* external DMA requests when tusb6010 is used */
+ { "musb-hdrc.1.auto", "dmareq0", SDMA_FILTER_PARAM(2) },
+ { "musb-hdrc.1.auto", "dmareq1", SDMA_FILTER_PARAM(3) },
+ { "musb-hdrc.1.auto", "dmareq2", SDMA_FILTER_PARAM(14) }, /* OMAP2420
only */
+ { "musb-hdrc.1.auto", "dmareq3", SDMA_FILTER_PARAM(15) }, /* OMAP2420
only */
+ { "musb-hdrc.1.auto", "dmareq4", SDMA_FILTER_PARAM(16) }, /* OMAP2420
only */
+ { "musb-hdrc.1.auto", "dmareq5", SDMA_FILTER_PARAM(64) }, /* OMAP2420
only */
};
static const struct dma_slave_map omap3xxx_sdma_map[] = {
@@ -346,6 +364,12 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *unused)
__func__);
return -ENODEV;
}
+ } else {
+ if (soc_is_omap24xx()) {
+ /* DMA slave map for drivers not yet converted to DT */
+ p.slave_map = omap24xx_sdma_dt_map;
+ p.slavecnt = ARRAY_SIZE(omap24xx_sdma_dt_map);
+ }
}
pdev = omap_device_build(name, 0, oh, &p, sizeof(p));
--
2.12.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] usb: musb: tusb6010_omap: Convert to DMAengine
Sorry, I have forgot to update the commit message for the last patch. On 2017-05-03 13:54, Peter Ujfalusi wrote: Hi, With port_window support implemented in DMAengine and the sDMA DMAengine driver, the tusb6010_omap driver can be converted away from the custom legacy omap-dma API to generic DMAengine. The first two patch is to prepare the tusb6010_omap driver for the conversion. The third one adds the needed entries for the dma_slave_map so we can request the DMA channels. This can be reverted when the stack is converted to DT. The last patch does the main work to move the driver to DMAengine API. I have tested the set on top of next-20170503 on Nokia n810 with nfsroot using CDC Ethernet (g_cdc) and copying files with scp to/form my host. To force that the DMA is actually used I have: diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c index 05aefcad40b5..a5fc2a6bdad3 100644 --- a/drivers/usb/musb/tusb6010_omap.c +++ b/drivers/usb/musb/tusb6010_omap.c @@ -216,8 +216,8 @@ static int tusb_omap_dma_program(struct dma_channel *channel, u16 packet_sz, * use a timer for the callback, but it is unsafe as the XFR_SIZE * register is corrupt, and we won't know if the DMA worked. */ - if (dma_addr & 0x2) - return false; +// if (dma_addr & 0x2) +// return false; /* * Because of HW issue #10, it seems like mixing sync DMA and async Since this condition will almost all the time was true - effectively disabling the DMA use. Regards. Peter --- Peter Ujfalusi (4): usb: musb: tusb6010_omap: Create new struct for DMA data/parameters usb: musb: tusb6010_omap: Allocate DMA channels upfront ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines usb: musb: tusb6010_omap: Convert to dmaengine WIP arch/arm/mach-omap2/dma.c| 24 +++ drivers/usb/musb/tusb6010_omap.c | 342 ++- 2 files changed, 177 insertions(+), 189 deletions(-) - Péter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I'd like to donate a MacBook Pro
On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: > 2017-05-01 3:03 GMT-06:00 Lukas Wunner : > > On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote: > >> I am confident that this is a common problem because I have found > >> various other users complaining about it: > >> > >> https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363 > >> https://bbs.archlinux.org/viewtopic.php?pid=1451053#p1451053 > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668105 > >> https://bugzilla.kernel.org/show_bug.cgi?id=115741 > > > > Briefly looking over those links I notice some people are reporting > > the same issue on macOS. This could indicate an EFI firmware bug > > or hardware issue. Have you tried updating the firmware? Has this > > issue always been present? > > Everything worked fine when I first installed Linux last October. I > updated the firmware immediately before installing Linux. I think it > was a couple of months before the boot problems showed up. > > 2017-05-01 4:06 GMT-06:00 Greg KH : > > You are not saying what kernel version you are using here, newer ones > > have fixed issues like this. Have you tried 4.10? 4.11? > > I am currently using 4.10. I tried 4.11 yesterday and the keyboard did > not work at all. The error messages changed to: > > [0.453518] ACPI Error: Needed type [Reference], found [Integer] > 88045bce > 3798 (20170119/exresop-103) > [0.453525] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands > for > [OpcodeName unavailable] (20170119/dswexec-461) > [0.453530] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] > (Node > 88045e0ee320), AE_AML_OPERAND_TYPE (20170119/psparse-543) > starting version 232 > > A password is required to access the cryptroot volume: > Enter passphrase for /dev/sda4: [7.950202] xhci_hcd :00:14.0: > Command completion event does not match command > [ 10.290329] usb 2-3: device not accepting address 2, error -62 > [ 20.537740] xhci_hcd :00:14:0: Command completion event does > not match command > [ 35.045403] xhci_hcd :00:14.0: Error while assigning device slot ID > [ 35.045659] xhci_hcd :00:14.0: Max number of devices this xHCI > host supports is 32. > [ 35.045934] usb usb2-port3: couldn't allocate usb_device > [ 47.419601] usb 1-3: hub failed to enable device, error -62 > [ 59.793777] xhci_hcd :00:14.0: Error while assigning device slot ID > [ 59.794032] xhci_hcd :00:14.0: Max number of devices this xHCI > host supports is 32. > [ 59.794307] usb usb1-port3: couldn't allocate usb_device > [ 72.167966] xhci_hcd :00:14.0: Error while assigning device slot ID > [ 72.168218] xhci_hcd :00:14.0: Max number of devices this xHCI > host supports is 32. > [ 72.168493] usb usb1-port5: couldn't allocate usb_device > > Today I ran a regression test to determine which commit made the > keyboard stop working entirely. The last commit that worked for me was > c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long > series of commits where the screen stays black, and after that, I > start getting errors like the one above. So git bisect said that commit was a good change, what one was the "bad" commit that git bisect pointed at? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I'd like to donate a MacBook Pro
2017-05-03 5:58 GMT-06:00 Greg KH : > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> Today I ran a regression test to determine which commit made the >> keyboard stop working entirely. The last commit that worked for me was >> c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long >> series of commits where the screen stays black, and after that, I >> start getting errors like the one above. > > So git bisect said that commit was a good change, what one was the "bad" > commit that git bisect pointed at? The commit right after that, but it's not clear whether the screen blanking problem was part of the same bug or just another bug that was introduced at about the same time. b0119e870837dcd15a207b4701542ebac5d19b45 is the first bad commit commit b0119e870837dcd15a207b4701542ebac5d19b45 Author: Joerg Roedel Date: Wed Feb 1 13:23:08 2017 +0100 iommu: Introduce new 'struct iommu_device' This struct represents one hardware iommu in the iommu core code. For now it only has the iommu-ops associated with it, but that will be extended soon. The register/unregister interface is also added, as well as making use of it in the Intel and AMD IOMMU drivers. Signed-off-by: Joerg Roedel :04 04 cb491d4d5bd25f1b65e6c93f7e67c8594901d6e1 84a5621c5e88961cf2385566c1c28eb5375c413f M drivers :04 04 5a2f0b8b829b29ef80baf6ef7cf2ba4b9bf23bf7 89ecaf2419fe0e00500c23413149f1df7bcbd693 M include -Alex -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I'd like to donate a MacBook Pro
On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: > 2017-05-03 5:58 GMT-06:00 Greg KH : > > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: > >> Today I ran a regression test to determine which commit made the > >> keyboard stop working entirely. The last commit that worked for me was > >> c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long > >> series of commits where the screen stays black, and after that, I > >> start getting errors like the one above. > > > > So git bisect said that commit was a good change, what one was the "bad" > > commit that git bisect pointed at? > > The commit right after that, but it's not clear whether the screen > blanking problem was part of the same bug or just another bug that was > introduced at about the same time. That would be 39ab9555c24110671f8dc671311a26e5c985b592: iommu: Add sysfs bindings for struct iommu_device And it introduced a regression when iommu-sysfs entries are accessed. This is fixed in a7fdb6e648fb. Does that commit fix the screen blanking problem? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chipidea USB controller hangs in peripheral mode under high memory bus pressure
Hi Peter,
On Wednesday 03 May 2017 11:10:55 Peter Chen wrote:
> On Tue, May 02, 2017 at 03:07:03PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > I ran into an issue with a Xilinx Zynq XC7Z010 system. The system acts as
> > a USB peripheral, using the UVC gadget driver.
> >
> > When transferring high bandwidth data over USB in isochronous mode,
> > complete system freezes are occasionally noticed. The problem was traced
> > to the following code from _hardware_enqueue() in
> > drivers/usb/chipidea/udc.c.
> >
> > wmb();
> > if (hw_read(ci, OP_ENDPTPRIME, BIT(n)))
> > goto done;
> > do {
> > hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
> > tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
> > } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
> > hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
> > if (tmp_stat)
> > goto done;
> >
> > The do ... while loop loops forever, and as the function is called under a
> > spin_lock_irqsave(), the system doesn't appreciate. Adding a maximum
> > number of iterations to exit the loop is easy (I'll try to submit a patch
> > after finding the root cause of the problem). That fixes the system hang,
> > but USB transfers are still broken.
> >
> > I've checked the code and unfortunately it seems to match the procedure
> > documented in the datasheet :-/
> >
> > The MTBF is several hours, but running 'memtester -M100'
> > (http://pyropus.ca/software/memtester/) in parallel to UVC video transfer
> > over USB brings the MTBF to a few minutes. The problem thus seems to be
> > related to memory bus pressure.
> >
> > Has anyone run into this problem before ? Is this a known issue ? I don't
> > mind getting my hands dirty debugging, but as I'm not familiar with the
> > chipidea USB controller pointers to what I should check in priority would
> > be appreciated.
>
> There was no one reported this problem before, but from the description,
> it seems an IC issue which is triggered at high loading memory bus,
> controller may not get time to visit memory at limited time. At
> Xilinx Zynq, its tx buffer is small, and less than 512 bytes (84bc70f94d81,
> "usb: chipidea: add xilinx zynq platform data"), and your throughput
> may be > (512 * 3) bytes/SoF, you can't use non-stream mode by reducing
> max packet size. I think you may observe many under-run at bus analyzer
> during the test.
>
> As a workaround, you may try to do below things:
>
> 1. Link more TDs before the UVC run
> 2. Comment out the code, you are stuck in, it is only useful for protect
> last td status which is handling or will be handled soon by hardware.
> /*
> do {
> hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
> tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
> } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
> hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
> if (tmp_stat)
> goto done;
> */
> 3. If it can let your test run more time, try change code like below:
>
> if (remaining_td_num > 2)
> don't do hardware check;
> else
> do hardware check.
>
>
> Besides, I can try your test if you could show me the detail test steps.
By the way, do you have access to a Xilinx Zynq-based board for testing ? If
you do, what board is that ? And if you don't, what board would you use ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace
On 05/01/2017 at 10:58 PM, Alan Stern wrote: > On Wed, 26 Apr 2017, Andreas Hartmann wrote: > >> On 04/24/2017 at 10:39 PM Alan Stern wrote: >>> On Sun, 23 Apr 2017, Andreas Hartmann wrote: >>> Am 23.04.2017 um 18:09 schrieb Alan Stern: > On Sat, 22 Apr 2017, Andreas Hartmann wrote: > >>> In the meanwhile, I see another problem. The SCSI residue value is >>> getting overwritten when new firmware is sent to the device. Like I >>> said >>> before, it's amazing this driver has ever worked. >> >> It depends on how you define "worked" ... > > How well _did_ it work in the past? As you already could see it: sometimes it has been working, sometimes not. It's been just chance. I was hoping to get it fixed this way. Some time ago, there was a OS driver provided by the manufacturer (?) (keucr), which worked without any problem (for me). But this driver was removed in 3.17 [1] and replaced by this one. This driver _never_ worked reliably. >>> >>> Ah. >>> I applied this new patch, too and attached the newly created debugs. But first of all: you are great! The loading of the SD card now works as expected! This is covered by the logfiles usb-ene-2*. It contains the physical removing w/o loading the filesystem before (i.e. w/o mount / unmount and remove procedure by software before) >>> >>> Well, the log does show that the patch wasn't quite correct. Below is >>> an updated version. >>> The second pair of logfiles usb-ene-3* covers a *new* problem during removing of SD cards via software after mount / umount. The problem is, that on removing it via GUI, suddenly *3* device entries appear, which could be activated (the same as the initial entry). After a few seconds, 2 of them disappeared again and one stays. This happens with two different SD cards here, another card doesn't show this problem. I would be very glad if you could fix this hopefully last issue, too :-) (if it is a problem at all). >>> >>> It's possible that the updated patch will help with all those >>> notifications. At least, the sense data should now be correct. >>> >>> As for the 3 device entries, I'm not sure where to look for them in >>> your logs. >> >> The remove part should start in usb-ene-3.log.gz with >> >> [ 4261.261188] *** thread awakened > > Starting from that point, the log file shows four apparently successful > writes, followed by what looks like a re-scan of the device and a bunch > of reads. Could it be that the rescan is responsible for those log entries, which can be seen after removal? A normal removal works like this: click on remove and after a few seconds (stating, that the device is ready to be removed now) the device entry disappears. In this case, it's working like this: Click on remove. Then always 3 device entries appear (stating, that the device could be removed now) and shortly after, there are two entries, each of them claiming that there are two actions for this device (opening with filemanager or with some other application). Some time later, one of those two entries disappear. With the resulting entry, the device can be reopened again (exactly the same entry as on initially plugged in card). >From my point of view, the device never got disabled - if it would have been disabled, it wouldn't be possible to reload it again after removing (by click) without replugging it. > >> In usb-ene-3.pcapng.gz it should start around package 2925. > > That is indeed where the disconnect first appears. > >> But to be honest - I'm missing some URB packages in the pcapng-file >> which are reported in the log file: Between package 2924 and 2925 are >> about 8s difference. I can't find this difference in the logfile. Is it >> possible that there are some URBs not being sent out? > > No, your files are correct. The last READ command finishes at > timestamp 4261.990022 in the log file (entry 2924 in the pcap file). > Everything after that is ALLOW MEDIUM REMOVAL, REQUEST SENSE, and TEST > UNIT READY until timestamp 4269.794577 (when the disconnect occurs), > and for those commands the driver does not perform any communication > with the device. > > Which for TEST UNIT READY, at least, is undoubtedly a bug. That > command should return a failure if the card has been removed, and > obviously it can't do that if it doesn't check with the device to see > whether the card is still present. > > There's still no indication of three extra device entries anywhere. > > Alan Stern > Thanks, kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asmedia USB 1343 crashes
On Tue, 2 May 2017, Thomas Fjellstrom wrote: > I just had a brief lockup, desktop stopped responding, other usb devices not > on the usb3 controller. Two android devices were in the process of restarting. > > It doesn't seem to matter what android devices it is. > > [294503.849350] [ cut here ] > [294503.849362] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 > dev_watchdog+0x223/0x230 > [294503.849365] NETDEV WATCHDOG: enp4s0 (igb): transmit queue 0 timed out > [294503.849367] Modules linked in: sr_mod cdrom ipt_MASQUERADE > nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 > nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter overlay > ebtable_filter ebtables ip6table_filter ip6_tables nfsv3 nfs_acl nfs lockd > grace iptable_filter bridge stp llc amdgpu mfd_core fuse vfat fat eeepc_wmi > asus_wmi rfkill edac_mce_amd edac_core pcspkr sg amdkfd radeon ttm sunrpc > k10temp it87 hwmon_vid fam15h_power efivarfs ip_tables ipv6 autofs4 > crc32c_intel i2c_piix4 > [294503.849407] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc7 #8 > [294503.849410] Hardware name: To be filled by O.E.M. To be filled by > O.E.M./970 PRO GAMING/AURA, BIOS 0901 11/07/2016 > [294503.849413] Call Trace: > [294503.849417] > [294503.849422] dump_stack+0x4d/0x63 > [294503.849426] __warn+0xc6/0xe0 > [294503.849430] warn_slowpath_fmt+0x46/0x50 > [294503.849434] dev_watchdog+0x223/0x230 > [294503.849438] ? qdisc_rcu_free+0x40/0x40 > [294503.849442] call_timer_fn+0x30/0x160 > [294503.849445] ? qdisc_rcu_free+0x40/0x40 > [294503.849448] run_timer_softirq+0x1e1/0x440 > [294503.849453] ? lapic_next_event+0x18/0x20 > [294503.849456] ? sched_clock_cpu+0x11/0xd0 > [294503.849459] __do_softirq+0x101/0x2f0 > [294503.849463] irq_exit+0xb9/0xc0 > [294503.849466] smp_apic_timer_interrupt+0x38/0x50 > [294503.849470] apic_timer_interrupt+0x86/0x90 > [294503.849474] RIP: 0010:acpi_idle_do_entry+0x2c/0x40 > [294503.849476] RSP: 0018:b2a03d90 EFLAGS: 0246 ORIG_RAX: > ff10 > [294503.849480] RAX: RBX: 884d1a966c00 RCX: > 0034 > [294503.849483] RDX: 4ec4ec4ec4ec4ec5 RSI: 0001 RDI: > 884d1a966c64 > [294503.849485] RBP: b2a03dd0 R08: 03e3 R09: > 0018 > [294503.849487] R10: 03c1 R11: 03d4 R12: > 884d1a966c64 > [294503.849490] R13: 0001 R14: 0001 R15: > 0001 > [294503.849492] > [294503.849497] ? acpi_idle_enter+0xd7/0x290 > [294503.849502] cpuidle_enter_state+0xed/0x2e0 > [294503.849506] cpuidle_enter+0x12/0x20 > [294503.849509] call_cpuidle+0x1e/0x30 > [294503.849512] do_idle+0x179/0x1d0 > [294503.849515] cpu_startup_entry+0x5d/0x60 > [294503.849518] rest_init+0x7f/0x90 > [294503.849522] start_kernel+0x405/0x412 > [294503.849525] x86_64_start_reservations+0x24/0x26 > [294503.849528] x86_64_start_kernel+0x182/0x193 > [294503.849531] start_cpu+0x14/0x14 > [294503.849534] ? start_cpu+0x14/0x14 > [294503.849537] ---[ end trace 12db587e781d6e4f ]--- > [294503.849558] igb :04:00.0 enp4s0: Reset adapter > [294504.576629] xhci_hcd :02:00.0: Stop command ring failed, maybe the > host is dead > [294504.576656] xhci_hcd :02:00.0: Abort command ring failed > [294504.576799] xhci_hcd :02:00.0: xHCI host not responding to stop > endpoint command. > [294504.576805] xhci_hcd :02:00.0: Assuming host is dying, halting host. At this point you have reached the limit of my knowledge. The best person to help is Mathias Nyman, the xHCI maintainer (CC'ed). Is that WARNING at the start of the log connected with the later events? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace
On Wed, 3 May 2017, Andreas Hartmann wrote: > >> The remove part should start in usb-ene-3.log.gz with > >> > >> [ 4261.261188] *** thread awakened > > > > Starting from that point, the log file shows four apparently successful > > writes, followed by what looks like a re-scan of the device and a bunch > > of reads. > > Could it be that the rescan is responsible for those log entries, which > can be seen after removal? Probably. But I'm having trouble understanding this. Which log entries in particular do you mean? The writes could be the system flushing its page buffer, and the reads could all be part of the re-scan. I didn't do a detailed comparison between the re-scan and the original scan near the start of the log. > A normal removal works like this: > click on remove and after a few seconds (stating, that the device is > ready to be removed now) the device entry disappears. It's difficult to know what this involves. Your GUI environment could be doing lots of stuff when you click on Remove. > In this case, it's working like this: > Click on remove. Then always 3 device entries appear (stating, that the > device could be removed now) and shortly after, there are two entries, > each of them claiming that there are two actions for this device > (opening with filemanager or with some other application). Some time > later, one of those two entries disappear. With the resulting entry, the > device can be reopened again (exactly the same entry as on initially > plugged in card). What do you mean by "3 device entries appear"? Where do they appear? What kind of device entries are they? > From my point of view, the device never got disabled - if it would have > been disabled, it wouldn't be possible to reload it again after removing > (by click) without replugging it. Why would clicking on Remove cause the device to be disabled? For that matter, exactly what do you mean when you talk about disabling the device? And which device are you trying to disable: the SCSI disk device or the USB card reader device? Is Remove supposed to be the same as unmount? Or is it supposed to tell the system that the memory card has been taken out of the reader? Bear in mind that the eneub6250 driver does not detect card removal correctly. If you want to change cards, the best approach would be to do a "safely remove hardware" and then unplug the reader from the computer and replug it with the new card inserted. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asmedia USB 1343 crashes
On Wednesday, May 3, 2017 1:54:39 PM MDT Alan Stern wrote: > On Tue, 2 May 2017, Thomas Fjellstrom wrote: > > > I just had a brief lockup, desktop stopped responding, other usb devices > > not > > on the usb3 controller. Two android devices were in the process of > > restarting. > > > > It doesn't seem to matter what android devices it is. > > > > [294503.849350] [ cut here ] > > [294503.849362] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 > > dev_watchdog+0x223/0x230 > > [294503.849365] NETDEV WATCHDOG: enp4s0 (igb): transmit queue 0 timed out > > [294503.849367] Modules linked in: sr_mod cdrom ipt_MASQUERADE > > nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 > > nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter > > overlay ebtable_filter ebtables ip6table_filter ip6_tables nfsv3 nfs_acl > > nfs lockd grace iptable_filter bridge stp llc amdgpu mfd_core fuse vfat fat > > eeepc_wmi asus_wmi rfkill edac_mce_amd edac_core pcspkr sg amdkfd radeon > > ttm sunrpc k10temp it87 hwmon_vid fam15h_power efivarfs ip_tables ipv6 > > autofs4 crc32c_intel i2c_piix4 > > [294503.849407] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc7 #8 > > [294503.849410] Hardware name: To be filled by O.E.M. To be filled by > > O.E.M./970 PRO GAMING/AURA, BIOS 0901 11/07/2016 > > [294503.849413] Call Trace: > > [294503.849417] > > [294503.849422] dump_stack+0x4d/0x63 > > [294503.849426] __warn+0xc6/0xe0 > > [294503.849430] warn_slowpath_fmt+0x46/0x50 > > [294503.849434] dev_watchdog+0x223/0x230 > > [294503.849438] ? qdisc_rcu_free+0x40/0x40 > > [294503.849442] call_timer_fn+0x30/0x160 > > [294503.849445] ? qdisc_rcu_free+0x40/0x40 > > [294503.849448] run_timer_softirq+0x1e1/0x440 > > [294503.849453] ? lapic_next_event+0x18/0x20 > > [294503.849456] ? sched_clock_cpu+0x11/0xd0 > > [294503.849459] __do_softirq+0x101/0x2f0 > > [294503.849463] irq_exit+0xb9/0xc0 > > [294503.849466] smp_apic_timer_interrupt+0x38/0x50 > > [294503.849470] apic_timer_interrupt+0x86/0x90 > > [294503.849474] RIP: 0010:acpi_idle_do_entry+0x2c/0x40 > > [294503.849476] RSP: 0018:b2a03d90 EFLAGS: 0246 ORIG_RAX: > > ff10 > > [294503.849480] RAX: RBX: 884d1a966c00 RCX: > > 0034 > > [294503.849483] RDX: 4ec4ec4ec4ec4ec5 RSI: 0001 RDI: > > 884d1a966c64 > > [294503.849485] RBP: b2a03dd0 R08: 03e3 R09: > > 0018 > > [294503.849487] R10: 03c1 R11: 03d4 R12: > > 884d1a966c64 > > [294503.849490] R13: 0001 R14: 0001 R15: > > 0001 > > [294503.849492] > > [294503.849497] ? acpi_idle_enter+0xd7/0x290 > > [294503.849502] cpuidle_enter_state+0xed/0x2e0 > > [294503.849506] cpuidle_enter+0x12/0x20 > > [294503.849509] call_cpuidle+0x1e/0x30 > > [294503.849512] do_idle+0x179/0x1d0 > > [294503.849515] cpu_startup_entry+0x5d/0x60 > > [294503.849518] rest_init+0x7f/0x90 > > [294503.849522] start_kernel+0x405/0x412 > > [294503.849525] x86_64_start_reservations+0x24/0x26 > > [294503.849528] x86_64_start_kernel+0x182/0x193 > > [294503.849531] start_cpu+0x14/0x14 > > [294503.849534] ? start_cpu+0x14/0x14 > > [294503.849537] ---[ end trace 12db587e781d6e4f ]--- > > [294503.849558] igb :04:00.0 enp4s0: Reset adapter > > [294504.576629] xhci_hcd :02:00.0: Stop command ring failed, maybe the > > host is dead > > [294504.576656] xhci_hcd :02:00.0: Abort command ring failed > > [294504.576799] xhci_hcd :02:00.0: xHCI host not responding to stop > > endpoint command. > > [294504.576805] xhci_hcd :02:00.0: Assuming host is dying, halting host. > > At this point you have reached the limit of my knowledge. The best > person to help is Mathias Nyman, the xHCI maintainer (CC'ed). > > Is that WARNING at the start of the log connected with the later > events? I belive so yes. Except for some usb adds/removals for the devices restarting. > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Thomas Fjellstrom tho...@fjellstrom.ca -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] USB: serial: ftdi_sio: fix setting latency for unprivileged users
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") enables unprivileged users to set the FTDI latency timer,
but there was a logic flaw that skipped sending the corresponding
USB control message to the device.
Signed-off-by: Anthony Mallet
---
drivers/usb/serial/ftdi_sio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index c540de1..bf04eea 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1505,9 +1505,9 @@ static int set_serial_info(struct tty_struct *tty,
(new_serial.flags & ASYNC_FLAGS));
priv->custom_divisor = new_serial.custom_divisor;
+check_and_exit:
write_latency_timer(port);
-check_and_exit:
if ((old_priv.flags & ASYNC_SPD_MASK) !=
(priv->flags & ASYNC_SPD_MASK)) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: serial: ftdi_sio: fix setting latency for unprivileged users
On Wednesday 3 May 2017, at 10:16, Johan Hovold wrote: | I could fix this up if you prefer, but I suggest you respin the patch as | a v2 (remember to add v2 inside the "[PATCH v2]" prefix and add a short | changelog below the cut-off line) so that you've mastered the full | process for next time. | | What do you say? Hi, I just resent a v2, hope this will be good. Thanks for your patience :) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: I'd like to donate a MacBook Pro
2017-05-03 8:58 GMT-06:00 Joerg Roedel : > On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: >> 2017-05-03 5:58 GMT-06:00 Greg KH : >> > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> >> Today I ran a regression test to determine which commit made the >> >> keyboard stop working entirely. The last commit that worked for me was >> >> c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long >> >> series of commits where the screen stays black, and after that, I >> >> start getting errors like the one above. >> > >> > So git bisect said that commit was a good change, what one was the "bad" >> > commit that git bisect pointed at? >> >> The commit right after that, but it's not clear whether the screen >> blanking problem was part of the same bug or just another bug that was >> introduced at about the same time. > > That would be 39ab9555c24110671f8dc671311a26e5c985b592: > > iommu: Add sysfs bindings for struct iommu_device > > And it introduced a regression when iommu-sysfs entries are accessed. > This is fixed in a7fdb6e648fb. > > Does that commit fix the screen blanking problem? At a7fdb6e648fb the screen works but the keyboard is broken. I think that the screen was actually fixed by an earlier commit, but when I tried to run a regression test to find when the keyboard problem appeared after the screen was fixed, I gave up because testing each revision takes about half an hour and the keyboard problem appears to be somewhat intermittent. -Alex -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Chipidea USB controller hangs in peripheral mode under high memory bus pressure
On Wed, May 03, 2017 at 01:32:28PM +0300, Laurent Pinchart wrote:
> >
> > There was no one reported this problem before, but from the description,
> > it seems an IC issue which is triggered at high loading memory bus,
> > controller may not get time to visit memory at limited time.
>
> That's my guess too. I was expecting the USB controller's bus master
> interface
> to get stalled but eventually perform the access (or retry it, I'm not sure
> what kind of bus it sits on), but there might be a hardware bug that messes
> up
> the controller's state machine. I won't rule out the possibility of a
> software
> issue yet, it might be possible to detect this condition and retry the
> transfer.
I am not sure if it can be recovered, you can call ->fifo_flush, and
->ep_disable and ->ep_enable if it returns -ETIME, and re-submit this
request.
>
> > At Xilinx Zynq, its tx buffer is small, and less than 512 bytes
> > (84bc70f94d81, "usb: chipidea: add xilinx zynq platform data"), and your
> > throughput may be > (512 * 3) bytes/SoF, you can't use non-stream mode by
> > reducing max packet size.
>
> My throughput is actually 1*1024 bytes / SOF.
>
>From previous discussion, the tx fifo size is 341.33 bytes for xilinx
zynq, you can set max packet size as 341 and mult as 3, then you can
transfer 1023 bytes / SoF for non-stream mode, assumed the non-stream
mode can fix your problem.
diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
b/drivers/usb/chipidea/ci_hdrc_usb2.c
index d162cc0..7229f2d 100644
--- a/drivers/usb/chipidea/ci_hdrc_usb2.c
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -33,6 +33,7 @@ static const struct ci_hdrc_platform_data ci_default_pdata = {
static struct ci_hdrc_platform_data ci_zynq_pdata = {
.capoffset = DEF_CAPOFFSET,
+ .flags = CI_HDRC_DISABLE_STREAMING,
};
> > I think you may observe many under-run at bus analyzer during the test.
>
> I'll try to get this checked (as I don't have a USB analyzer here).
>
> > As a workaround, you may try to do below things:
> >
> > 1. Link more TDs before the UVC run
>
> Do you mean I should have more requests queued to avoid hitting the
> software/hardware race that the loop handles ?
Yes, you can comment out that code if you have more pending dTDs.
>
> > 2. Comment out the code, you are stuck in, it is only useful for protect
> > last td status which is handling or will be handled soon by hardware.
> >
> > /*
> > do {
> > hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
> > tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
> > } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
> > hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
> > if (tmp_stat)
> > goto done;
> > */
>
> I'm not familiar with this driver, but if I understand things correctly, the
> code (and the "TD tripwire" hardware feature) is here to handle a race
> condition where the hardware could look at the last TD's next pointer at the
> same time it gets updated by the software. If I comment the code out, won't
> the endpoint will be primed unconditionally, even if it's currently executing
> transfers ? Won't that be a problem ?
Try below code, I have tested it using qmult=20 for NCM.
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d68b125..dbef51a 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -485,13 +485,19 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep,
struct ci_hw_req *hwreq)
wmb();
if (hw_read(ci, OP_ENDPTPRIME, BIT(n)))
goto done;
- do {
- hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
- tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
- } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
- hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
- if (tmp_stat)
- goto done;
+
+ if (ci->ep0out == hwep || ci->ep0in == hwep) {
+ do {
+ hw_write(ci, OP_USBCMD, USBCMD_ATDTW,
USBCMD_ATDTW);
+ tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
+ } while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
+ hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
+ if (tmp_stat)
+ goto done;
+ } else {
+ if(hw_read(ci, OP_ENDPTSTAT, BIT(n)))
+ goto done;
+ }
}
/* QH configuration */
>
> > 3. If it can let your test run more time, try change code like below:
> >
> > if (remaining_td_num > 2)
> > don't do hardware check;
> > else
> > do hardware check.
>
> I'll test that, but I assume I'm hitting the problem when the number of
