Re: [PATCH v3 2/2] USB: EHCI: Allow users to override 80% max periodic bandwidth

2011-07-02 Thread Kirill Smelkov
On Fri, Jul 01, 2011 at 02:24:27PM -0700, Greg KH wrote:
 On Fri, Jul 01, 2011 at 03:47:11PM +0400, Kirill Smelkov wrote:
   drivers/usb/host/ehci-sysfs.c |  104 
  +++--
 
 As you are adding new sysfs files, it is required that you also add new
 entries in the Documentation/ABI/ directory.
 
 Please do that for these files so that people have an idea of what they
 are, and how to use them.
 
 Care to redo this series with that change?

Sure, I'll post v4 with documentation included.

Thanks,
Kirill
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 2/2] USB: EHCI: Allow users to override 80% max periodic bandwidth

2011-07-01 Thread Kirill Smelkov
There are cases, when 80% max isochronous bandwidth is too limiting.

For example I have two USB video capture cards which stream uncompressed
video, and to stream full NTSC + PAL videos we'd need

NTSC 640x480 YUV422 @30fps  ~17.6 MB/s
PAL  720x576 YUV422 @25fps  ~19.7 MB/s

isoc bandwidth.

Now, due to limited alt settings in capture devices NTSC one ends up
streaming with max_pkt_size=2688  and  PAL with max_pkt_size=2892, both
with interval=1. In terms of microframe time allocation this gives

NTSC~53us
PAL ~57us

and together

~110us100us == 80% of 125us uframe time.

So those two devices can't work together simultaneously because the'd
over allocate isochronous bandwidth.

80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
both devices started to work together, so I though sometimes it would be
a good idea for users to override hardcoded default of max 80% isoc
bandwidth.

After all, isn't it a user who should decide how to load the bus? If I
can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
newcomer, but that 80% set in stone by USB 2.0 specification seems to be
chosen pretty arbitrary to me, just to serve as a reasonable default.

NOTE 1
~~

for two streams with max_pkt_size=3072 (worst case) both time
allocation would be 60us+60us=120us which is 96% periodic bandwidth
leaving 4% for bulk and control.  Alan Stern suggested that bulk then
would be problematic (less than 300*8 bittimes left per microframe), but
I think that is still enough for control traffic.

NOTE 2
~~

Sarah Sharp expressed concern that maxing out periodic bandwidth
could lead to vendor-specific hardware bugs on host controllers, because

 It's entirely possible that you'll run into
 vendor-specific bugs if you try to pack the schedule with isochronous
 transfers.  I don't think any hardware designer would seriously test or
 validate their hardware with a schedule that is basically a violation of
 the USB bus spec (more than 80% for periodic transfers).

So far I've only tested this patch on my HP Mini 5103 with N10 chipeset

kirr@mini:~$ lspci
00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge
00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated 
Graphics Controller
00:02.1 Display controller: Intel Corporation N10 Family Integrated 
Graphics Controller
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition 
Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 
(rev 02)
00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 
(rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI 
Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI 
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI 
Controller (rev 02)
01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n 
Wireless LAN Controller (rev 01)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E 
Gigabit Ethernet Controller (rev 11)

and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for
above-mentioned isochronous transfers.

NOTE 3
~~

This feature is off by default. I mean max periodic bandwidth is set to
100us/uframe by default exactly as it was before the patch. So only those of us
who need the extreme settings are taking the risk - normal users who do not
alter uframe_periodic_max sysfs attribute should not see any change at all.

Cc: Sarah Sharp sarah.a.sh...@linux.intel.com
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
 drivers/usb/host/ehci-hcd.c   |6 ++
 drivers/usb/host/ehci-sched.c |   17 +++
 drivers/usb/host/ehci-sysfs.c |  104 +++--
 drivers/usb/host/ehci.h   |2 +
 4 files changed, 115 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8306155..4ee62be 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -572,6 +572,12 @@ static int ehci_init(struct usb_hcd *hcd)
hcc_params = ehci_readl(ehci, ehci-caps-hcc_params);
 
/*
+* by default set standard 80% (== 100 usec/uframe) max periodic
+* bandwidth as required by USB 2.0
+*/
+   ehci-uframe_periodic_max = 100;
+
+   /*
 * hw default: 1K periodic list heads, one per frame.
 * 

Re: [PATCH v3 2/2] USB: EHCI: Allow users to override 80% max periodic bandwidth

2011-07-01 Thread Greg KH
On Fri, Jul 01, 2011 at 03:47:11PM +0400, Kirill Smelkov wrote:
  drivers/usb/host/ehci-sysfs.c |  104 
 +++--

As you are adding new sysfs files, it is required that you also add new
entries in the Documentation/ABI/ directory.

Please do that for these files so that people have an idea of what they
are, and how to use them.

Care to redo this series with that change?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html