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
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
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.
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 +-
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 doe
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
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]
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:
>
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 transferr
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
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, t
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://b
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 ye
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
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/mus
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
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
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/mu
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
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 gadge
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
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
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.
>
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
24 matches
Mail list logo
