Re: [PATCH v3 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1

2018-01-07 Thread Simon Horman 
On Fri, Jan 05, 2018 at 05:46:46PM -0500, Chris Brandt wrote:
> Document support for RZ/A1 SoCs
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
>  * Removed "renesas,usbhs-r7s72100"

Unless I am mistaken you want both renesas,usbhs-r7s72100, for the SoC
and renesas,rza1-usbhs for the family[*] of SoCs (which currently only has one
member upstream).

Similar to the way there are per-SoC compat strings for R-Car Gen2 and Gen3
SoCs, and per-SoC family fallback compat strings to Gen2 and Gen3.

The motivation for this that empirically SoC families seem to be able to
share the implementation on the driver-side, so only the fallback compat
strings need to be implemented in the driver by defining per-SoC compat
strings we have the flexibility to implement them if differences emerge
between SoCs in the same family.

[*] I used the term family here to group SoCs together. I acknowledge that
Renesas may not refer to them in this way.



> v2:
>  * Added Reviewed-by
> ---
>  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index 47394ab788e3..fa16d8d33815 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -15,6 +15,7 @@ Required properties:
>   - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device
>   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices
>   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
> + - "renesas,rza1-usbhs" for RZ/A1 compatible device
>  
>   When compatible with the generic version, nodes must list the
>   SoC-specific version corresponding to the platform first followed
> -- 
> 2.15.1
> 
> 
--
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 v3 3/3] ARM: dts: r7s72100: add USB device to device tree

2018-01-07 Thread Simon Horman 
On Fri, Jan 05, 2018 at 05:46:47PM -0500, Chris Brandt wrote:
> Add USB device support.
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
>  * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs"

I think you want both. The SoC-specific compat string followed by a fallback
compat string for something broader:

Like this:

compatible = "renesas,usbhs-r7s72100", "renesas,rza1-usbhs";

> v2:
>  * Node name is now generic 'usb@'
>  * GIC_SPI (73-32) is now just GIC_SPI 41
>  * All hex number are lower case
>  * Added Reviewed-by
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index ab9645a42eca..d94431767913 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -667,4 +667,24 @@
>   power-domains = <_clocks>;
>   status = "disabled";
>   };
> +
> + usbhs0: usb@e801 {
> + compatible = "renesas,rza1-usbhs";
> + reg = <0xe801 0x1a0>;
> + interrupts = ;
> + clocks = <_clks R7S72100_CLK_USB0>;
> + renesas,buswait = <4>;
> + power-domains = <_clocks>;
> + status = "disabled";
> + };
> +
> + usbhs1: usb@e8207000 {
> + compatible = "renesas,rza1-usbhs";
> + reg = <0xe8207000 0x1a0>;
> + interrupts = ;
> + clocks = <_clks R7S72100_CLK_USB1>;
> + renesas,buswait = <4>;
> + power-domains = <_clocks>;
> + status = "disabled";
> + };
>  };
> -- 
> 2.15.1
> 
> 
--
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 v3 3/3] ARM: dts: r7s72100: add USB device to device tree

2018-01-07 Thread Geert Uytterhoeven 
On Fri, Jan 5, 2018 at 11:46 PM, Chris Brandt  wrote:
> Add USB device support.
>
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
>  * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs"

Please use both, cfr. my reply to the cover letter.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 0/3] usb: renesas_usbhs: Add RZ/A1 support

2018-01-07 Thread Geert Uytterhoeven 
Hi Chris,

On Fri, Jan 5, 2018 at 11:46 PM, Chris Brandt  wrote:
> This series adds RZ/A1 gadget support to the renesas_usbhs driver.
> Basically, it's almost the same HW as the R-Car (and SH) parts.
> The only real difference is the some extra registers for the PHY.
>
> This was tested on an RSK board by connecting to a PC as an
> Ethernet CDC gadget.
>
> v3:
>  * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs"
>  * Removed "renesas,usbhs-r7s72100"
>  * Changed License of rza.c

Thanks for the update, but I think there has been a misunderstanding.
I didn't mean to drop "renesas,usbhs-r7s72100" everywhere, only from
the matching in the driver.

Summarized:
1. DT bindings should document _all_ compatible values (SoC-specific,
   and/or family-specific, generic, ...),
2. DTS should list _all applicable_ compatible values, ordered from
most-specific to least-specific,
3. Drivers should match against the least-specific compatible value to get
   the job done.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1

2018-01-07 Thread Geert Uytterhoeven 
Hi Chris,

On Fri, Jan 5, 2018 at 11:46 PM, Chris Brandt  wrote:
> Document support for RZ/A1 SoCs
>
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
>  * Removed "renesas,usbhs-r7s72100"

Please don't, cfr. my reply to the cover letter.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: kernel BUG at ./include/linux/mm.h:LINE! (3)

2018-01-07 Thread Pete Zaitcev 
On Fri, 29 Dec 2017 16:24:20 +0300
"Kirill A. Shutemov"  wrote:

> Looks like MON_IOCT_RING_SIZE reallocates ring buffer without any
> serialization wrt mon_bin_vma_fault(). By the time of get_page() the page
> may be freed.

As an update: I tried to make a smaller test for this, but was unsuccessful
so far. I'll poke a bit at it later, but it may take me some time.

-- Pete
--
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 v4 14/16] phy: Add USB speed related PHY modes

2018-01-07 Thread Manu Gautam 
Hi,

On 1/5/2018 4:31 PM, Kishon Vijay Abraham I wrote:
>> +enum phy_mode phy_get_mode(struct phy *phy)
>> +{
>> +enum phy_mode ret;
>> +
>> +if (!phy || !phy->ops->get_mode)
>> +return PHY_MODE_INVALID;
>> +
>> +mutex_lock(>mutex);
>> +ret = phy->ops->get_mode(phy);
> Since get_mode only has to return the phy mode, there is no need for an ops
> here. Just add phy_mode in phy_attrs in set_mode and return it here.

Sure, will re-send patch set with this change.


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: ohci: da8xx: remove clk con_id

2018-01-07 Thread David Lechner 

On 01/05/2018 07:53 PM, David Lechner wrote:

The ohci-da8xx device only has one clock, so a con_id is not needed, so
remove it. This way we don't have to add an unnecessary property to the
device tree bindings for the clock.

Signed-off-by: David Lechner 
---


superseded by https://marc.info/?l=linux-usb=151529526103513=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] USB: musb: da8xx: remove clock con_id

2018-01-07 Thread David Lechner 

On 01/05/2018 07:50 PM, David Lechner wrote:

There is only one clock for the DA8xx MUSB device, so we don't need the
con_id, so remove it. This way we don't have to add an unnecessary
property to the device tree bindings for the clock.

Signed-off-by: David Lechner 
---


superseded by https://marc.info/?l=linux-usb=151529526103513=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: dvb usb issues since kernel 4.9

2018-01-07 Thread Linus Torvalds 
On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab
 wrote:
>
> Em Sat, 6 Jan 2018 16:04:16 +0100
> "Josef Griebichler"  escreveu:
>>
>> the causing commit has been identified.
>> After reverting commit 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882
>> its working again.
>
> Just replying to me won't magically fix this. The ones that were involved on
> this patch should also be c/c, plus USB people. Just added them.

Actually, you seem to have added an odd subset of the people involved.

For example, Ingo - who actually committed that patch - wasn't on the cc.

I do think we need to simply revert that patch. It's very simple: it
has been reported to lead to actual problems for people, and we don't
fix one problem and then say "well, it fixed something else" when
something breaks.

When something breaks, we either unbreak it, or we revert the change
that caused the breakage.

It's really that simple. That's what "no regressions" means.  We don't
accept changes that cause regressions. This one did.

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

Aw: Re: dvb usb issues since kernel 4.9

2018-01-07 Thread Josef Griebichler 
Hi,

here I provide lsusb from my affected hardware (technotrend s2-4600).
http://ix.io/DLY

With this hardware I had errors when recording with tvheadend. Livetv was ok, 
only channel switching made some problems sometimes. Please see attached 
tvheadend service logs.

I also provide dmesg (libreelec on rpi3 with kernel 4.14.10 with revert of the 
mentioned commit).
http://ix.io/DM2


Regards
Josef
 
 

Gesendet: Sonntag, 07. Januar 2018 um 16:41 Uhr
Von: "Alan Stern" 
An: "Mauro Carvalho Chehab" 
Cc: "Josef Griebichler" , "Greg Kroah-Hartman" 
, linux-usb@vger.kernel.org, "Eric Dumazet" 
, "Rik van Riel" , "Paolo Abeni" 
, "Hannes Frederic Sowa" , "Jesper 
Dangaard Brouer" , linux-kernel 
, netdev , "Jonathan 
Corbet" , LMML , "Peter Zijlstra" 
, "David Miller" , 
torva...@linux-foundation.org
Betreff: Re: dvb usb issues since kernel 4.9
On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote: > > > It seems that the 
original patch were designed to solve some IRQ issues > > > with network cards 
with causes data losses on high traffic. However, > > > it is also causing bad 
effects on sustained high bandwidth demands > > > required by DVB cards, at 
least on some USB host drivers. > > > > > > Alan/Greg/Eric/David: > > > > > > 
Any ideas about how to fix it without causing regressions to > > > network? > > 
> > It would be good to know what hardware was involved on the x86 system > > 
and to have some timing data. Can we see the output from lsusb and > > usbmon, 
running on a vanilla kernel that gets plenty of video glitches? > > From 
Josef's report, and from the BZ, the affected hardware seems > to be based on 
Montage Technology M88DS3103/M88TS2022 chipset. What type of USB host 
controller does the x86_64 system use? EHCI or xHCI? > The driver it uses is at 
drivers/media/usb/dvb-usb-v2/dvbsky.c, > with shares a USB implementation that 
is used by a lot more drivers. > The URB handling code is at: > > 
drivers/media/usb/dvb-usb-v2/usb_urb.c > > This particular driver allocates 8 
buffers with 4096 bytes each > for bulk transfers, using transfer_flags = 
URB_NO_TRANSFER_DMA_MAP. > > This become a popular USB hardware nowadays. I 
have one S960c > myself, so I can send you the lsusb from it. You should 
notice, however, > that a DVB-C/DVB-S2 channel can easily provide very high 
sustained bit > rates. Here, on my DVB-S2 provider, a typical transponder 
produces 58 Mpps > of payload after removing URB headers. You mentioned earlier 
that the driver uses bulk transfers. In USB-2.0, the maximum possible payload 
data transfer rate using bulk transfers is 53248 bytes/ms, which is 53.248 MB/s 
(i.e., lower than 58 MB/s). And even this is possible only if almost nothing 
else is using the bus at the same time. > A 10 minutes record with the > entire 
data (with typically contains 5-10 channels) can easily go > above 4 GB, just 
to reproduce 1-2 glitches. So, I'm not sure if > a usbmon dump would be useful. 
It might not be helpful at all. However, I'm not interested in the payload data 
(which would be unintelligible to me anyway) but rather the timing of URB 
submissions and completions. A usbmon trace which didn't keep much of the 
payload data would only require on the order of 50 MB per minute -- and Josef 
said that glitches usually would show up within a minute or so. > I'm enclosing 
the lsusb from a S960C device, with is based on those > Montage chipsets: What 
I wanted to see was the output from "lsusb" on the affected system, not the 
output from "lsusb -v -s B:D" on your system. > > Overall, this may be a very 
difficult problem to solve. The > > 4cd13c21b207 commit was intended to improve 
throughput at the cost of > > increased latency. But then what do you do when 
the latency becomes > > too high for the video subsystem to handle? > > Latency 
can't be too high, otherwise frames will be dropped. Yes, that's the whole 
point. > Even if the Kernel itself doesn't drop, if the delay goes higher > 
than a certain threshold, userspace will need to drop, as it > should be 
presenting audio and video on real time. Yet, typically, > userspace will delay 
it by one or two seconds, with would mean > 1500-3500 buffers, with I suspect 
it is a lot more than the hardware > limits. So I suspect that the hardware 
starves free buffers a way > before userspace, as media hardware don't have 
unlimited buffers > inside them, as they assume that the Kernel/userspace will 
be fast > enough to sustain bit rates up to 66 Mbps of payload. The timing 
information would tell us how large the latency is. In any case, you might be 
able to attack the problem simply by using more than 8

Re: dvb usb issues since kernel 4.9

2018-01-07 Thread Alan Stern 
On Sun, 7 Jan 2018, Mauro Carvalho Chehab wrote:

> > > It seems that the original patch were designed to solve some IRQ issues
> > > with network cards with causes data losses on high traffic. However,
> > > it is also causing bad effects on sustained high bandwidth demands
> > > required by DVB cards, at least on some USB host drivers.
> > > 
> > > Alan/Greg/Eric/David:
> > > 
> > > Any ideas about how to fix it without causing regressions to
> > > network?  
> > 
> > It would be good to know what hardware was involved on the x86 system
> > and to have some timing data.  Can we see the output from lsusb and
> > usbmon, running on a vanilla kernel that gets plenty of video glitches?
> 
> From Josef's report, and from the BZ, the affected hardware seems
> to be based on Montage Technology M88DS3103/M88TS2022 chipset.

What type of USB host controller does the x86_64 system use?  EHCI or
xHCI?

> The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c,
> with shares a USB implementation that is used by a lot more drivers.
> The URB handling code is at:
> 
>   drivers/media/usb/dvb-usb-v2/usb_urb.c
> 
> This particular driver allocates 8 buffers with 4096 bytes each
> for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP.
> 
> This become a popular USB hardware nowadays. I have one S960c
> myself, so I can send you the lsusb from it. You should notice, however,
> that a DVB-C/DVB-S2 channel can easily provide very high sustained bit
> rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps
> of payload after removing URB headers.

You mentioned earlier that the driver uses bulk transfers.  In USB-2.0,
the maximum possible payload data transfer rate using bulk transfers is
53248 bytes/ms, which is 53.248 MB/s (i.e., lower than 58 MB/s).  And
even this is possible only if almost nothing else is using the bus at
the same time.

> A 10 minutes record with the
> entire data (with typically contains 5-10 channels) can easily go
> above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if
> a usbmon dump would be useful.

It might not be helpful at all.  However, I'm not interested in the 
payload data (which would be unintelligible to me anyway) but rather 
the timing of URB submissions and completions.  A usbmon trace which 
didn't keep much of the payload data would only require on the order of 
50 MB per minute -- and Josef said that glitches usually would show up 
within a minute or so.

> I'm enclosing the lsusb from a S960C device, with is based on those
> Montage chipsets:

What I wanted to see was the output from "lsusb" on the affected
system, not the output from "lsusb -v -s B:D" on your system.

> > Overall, this may be a very difficult problem to solve.  The
> > 4cd13c21b207 commit was intended to improve throughput at the cost of
> > increased latency.  But then what do you do when the latency becomes
> > too high for the video subsystem to handle?
> 
> Latency can't be too high, otherwise frames will be dropped.

Yes, that's the whole point.

> Even if the Kernel itself doesn't drop, if the delay goes higher
> than a certain threshold, userspace will need to drop, as it
> should be presenting audio and video on real time. Yet, typically,
> userspace will delay it by one or two seconds, with would mean
> 1500-3500 buffers, with I suspect it is a lot more than the hardware
> limits. So I suspect that the hardware starves free buffers a way 
> before userspace, as media hardware don't have unlimited buffers
> inside them, as they assume that the Kernel/userspace will be fast
> enough to sustain bit rates up to 66 Mbps of payload.

The timing information would tell us how large the latency is.

In any case, you might be able to attack the problem simply by using
more than 8 buffers.  With just eight 4096-byte buffers, the total
pipeline capacity is only about 0.62 ms (at the maximum possible
transfer rate).  Increasing the number of buffers to 65 would give a
capacity of 5 ms, which is probably a lot better suited for situations
where completions are handled by the ksoftirqd thread.

> Perhaps media drivers could pass some quirk similar to URB_ISO_ASAP,
> in order to revert the kernel logic to prioritize latency instead of
> throughput.

It can't be done without pervasive changes to the USB subsystem, which
I would greatly prefer to avoid.  Besides, this wouldn't really solve
the problem.  Decreasing the latency for one device will cause it to be
increased for others.

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: [RFC] Re: usb: gadget: ffs: Fix BUG when userland exits with submitted AIO transfers

2018-01-07 Thread Vincent Pelletier 
On Fri, 1 Dec 2017 00:14:52 +, Vincent Pelletier
 wrote:
> I'll play some more with a kernel with this patch
> to see if it breaks, and will resubmit if it looks fine.

Some update: this patch looks good on DWC3: both unplugging and
unbinding the UDC while AOI transfers are queued works fine.

What I intended to do is to also test it on DWC2, so I bought a
raspberry pi zero W (ie, with embedded wifi chip on SDIO), but the fail
is strong with me and I just cannot get a custom kernel build to boot
(blocks right after detecting mmc0 & mmc1 and listing MMC partitions),
so I could not extend my tests yet. I'll keep trying, but testers with
a DWC2 or other UDC are very welcome to give that patch a try.

To help with tests, here is my test scenario:

On both sides:
$ git clone https://github.com/vpelletier/python-functionfs.git
$ mkdir venv
$ virtualenv venv/
$ cd python-functionfs/
$ ../venv/bin/python setup.py install

On gadget only:
$ cd ..
$ sudo aptitude install libaio1
$ git clone https://github.com/vpelletier/python-libaio.git
$ cd python-libaio/
$ ../venv/bin/python setup.py install

Create a gadget device. My cheat sheet:
https://github.com/vpelletier/python-functionfs/tree/master/functionfs/tests

On gadget:
$ python -u slowprinter.py | venv/bin/python -u device.py 
/path/to/ffs_mountpoint

On host (re-run after disconnects, scripts come from
python-functionfs repository):
$ python -u slowprinter.py | venv/bin/python -u host.py

Plus udev rules to grant current host user access to the usb device.

Each side should print the time from other side every second, plus
some tracing blather. Test passes if gadget kernel is happy after
multiple unplug/plug cycles and both ends can still communicate after
re-plugging and restarting host script.

Regards,
-- 
Vincent Pelletier
--
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: dvb usb issues since kernel 4.9

2018-01-07 Thread Mauro Carvalho Chehab 
Em Sat, 6 Jan 2018 16:44:20 -0500 (EST)
Alan Stern  escreveu:

> On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote:
> 
> > Hi Josef,
> > 
> > Em Sat, 6 Jan 2018 16:04:16 +0100
> > "Josef Griebichler"  escreveu:
> >   
> > > Hi,
> > > 
> > > the causing commit has been identified.
> > > After reverting commit 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cd13c21b207e80ddb1144c576500098f2d5f882
> > > its working again.  
> > 
> > Just replying to me won't magically fix this. The ones that were involved on
> > this patch should also be c/c, plus USB people. Just added them.
> >   
> > > Please have a look into the thread 
> > > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?pageNo=13
> > > here are several users aknowledging the revert solves their issues with 
> > > usb dvb cards.  
> > 
> > I read the entire (long) thread there. In order to make easier for the
> > others, from what I understand, the problem happens on both x86 and arm,
> > although almost all comments there are mentioning tests with raspbian
> > Kernel (with uses a different USB host driver than the upstream one).
> > 
> > It happens when watching digital TV DVB-C channels, with usually means
> > a sustained bit rate of 11 MBps to 54 MBps.
> > 
> > The reports mention the dvbsky, with uses USB URB bulk transfers.
> > On every several minutes (5 to 10 mins), the stream suffer "glitches"
> > caused by frame losses.
> > 
> > The part of the thread that contains the bisect is at:
> > 
> > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965
> > 
> > It indirectly mentions another comment on the thread with points
> > to:
> > https://github.com/raspberrypi/linux/issues/2134
> > 
> > There, it says that this fix part of the issues:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34f41c0316ed52b0b44542491d89278efdaa70e4
> > 
> > but it affects URB packet losses on a lesser extend.
> > 
> > The main issue is really the logic changes a the core softirq logic.
> > 
> > Using Kernel 4.14.10 on a Raspberry Pi 3 with 4cd13c2 commit reverted
> > fixed the issue. 
> > 
> > Joseph, is the above right? Anything else to mention? Does the
> > same issue affect also on x86 with vanilla Kernel 4.14.10?
> > 
> > -
> > 
> > It seems that the original patch were designed to solve some IRQ issues
> > with network cards with causes data losses on high traffic. However,
> > it is also causing bad effects on sustained high bandwidth demands
> > required by DVB cards, at least on some USB host drivers.
> > 
> > Alan/Greg/Eric/David:
> > 
> > Any ideas about how to fix it without causing regressions to
> > network?  
> 
> It would be good to know what hardware was involved on the x86 system
> and to have some timing data.  Can we see the output from lsusb and
> usbmon, running on a vanilla kernel that gets plenty of video glitches?

>From Josef's report, and from the BZ, the affected hardware seems
to be based on Montage Technology M88DS3103/M88TS2022 chipset.
The driver it uses is at drivers/media/usb/dvb-usb-v2/dvbsky.c,
with shares a USB implementation that is used by a lot more drivers.
The URB handling code is at:

drivers/media/usb/dvb-usb-v2/usb_urb.c

This particular driver allocates 8 buffers with 4096 bytes each
for bulk transfers, using transfer_flags = URB_NO_TRANSFER_DMA_MAP.

This become a popular USB hardware nowadays. I have one S960c
myself, so I can send you the lsusb from it. You should notice, however,
that a DVB-C/DVB-S2 channel can easily provide very high sustained bit
rates. Here, on my DVB-S2 provider, a typical transponder produces 58 Mpps
of payload after removing URB headers. A 10 minutes record with the
entire data (with typically contains 5-10 channels) can easily go
above 4 GB, just to reproduce 1-2 glitches. So, I'm not sure if
a usbmon dump would be useful.

I'm enclosing the lsusb from a S960C device, with is based on those
Montage chipsets:

Bus 002 Device 007: ID 0572:960c Conexant Systems (Rockwell), Inc. DVBSky S960C 
DVB-S2 tuner
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0572 Conexant Systems (Rockwell), Inc.
  idProduct  0x960c DVBSky S960C DVB-S2 tuner
  bcdDevice0.00
  iManufacturer   1 
  iProduct2 
  iSerial 3 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  219
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4