All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: David Brownell <david-b@pacbell.net>
Cc: "Lev A. Melnikovsky" <melnikovsky@mail.ru>,
	Alessandro Suardi <alessandro.suardi@gmail.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: ehci-hcd affects hda speed
Date: Tue, 18 Mar 2008 02:23:57 +0100	[thread overview]
Message-ID: <47DF19AD.405@keyaccess.nl> (raw)
In-Reply-To: <200803171700.26274.david-b@pacbell.net>

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On 18-03-08 01:00, David Brownell wrote:

> On Monday 17 March 2008, Rene Herman wrote:
>> +       case PCI_VENDOR_ID_VIA:
>> +               if (pdev->device == 0x3104 && pdev->revision >= 0x60) {
> 
> Unless you have specific docs from VIA saying that this register
> isn't revision-specific (at least in the sense that all revisions
> after 0x60 define that bit in that way), this should probably be a
> switch on pdev->revision and just include the known-safe revisions.

I'm looking at a VIA datasheet which says the revision ID for the "VT6212 / 
VT6212L PCI USB2.0 Controller" is simply 0x60. The VT61212L I myself owned 
advertised a revision ID of 0x63 and Lev's VT6212L advertises 0x65.

The thing is -- you don't necesarily immediately notice this problem. I 
noticed it earlier on an old system, as did Lev, but even if on a modern 
system you may not immediately see an IDE throughput drop, you may still 
have a sucky system.

With 0x60 documented and 0x63 and 0x65 confirmed as VT6212L, I'd personally 
still go with >= 0x60 and assume either backwards-compatibility or a "don't 
care" definition if some later revision were to not define this hack.

> At one point I had a table mapping those revision codes to
> specific VIA chips.  Too bad I didn't keep it.  ISTR that the
> VT6212 has a newer revision code than the vt8235 southbridge,
> and probably not as new as the vt8237 one...

Some googling seems to indicate that:

VT6202 = 0x5x (0x50, 0x51 at least)
VT6212 = 0x6x (0x60, 0x61, 0x63, 0x65 at least)
VT8235 = 0x82
VT8237 = 0x86
VT*800 = 0x90 (KM800Pro, VN800, K8N800, ...)

Do you want one with 0x6x? I feel it's very likely that everyone on anything 
later will then still have a sucky system. Tons of people with VT8235/VT8237 
around (although not me). Any quick test available for them?

> But otherwise, yes -- that's the kind of patch I'd sign off on
> after making this comment a bit more informative about how
> that 1 usec sleep time creates an amount of PCI bus hogging.

Version with 0x6x and the somewhat more expansive comment. I'd like to be 
able to test VT8235/VT8237 first though...

Still totally untested ofcourse.

Rene

[-- Attachment #2: vt6212_ehci_sleep_time.diff --]
[-- Type: text/plain, Size: 1177 bytes --]

commit fd96c2b26339f21a66504cb3f36579bb312a8f3b
Author: Rene Herman <rene.herman@gmail.com>
Date:   Tue Mar 18 00:02:16 2008 +0100

    USB: VIA VT6212(L) 10us EHCI sleep time select.
    
    The VIA VT6212(L) uses a 1us EHCI sleep time by default which hogs
    the bus bad. Use the 10us EHCI spec value instead as suggested by
    Lev A. Melnikovsky.
    
    CC: Lev A. Melnikovsky <melnikovsky@mail.ru>
    Signed-off-by: Rene Herman <rene.herman@gmail.com>

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 3ba0166..bdc8af9 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -152,6 +152,20 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
 			break;
 		}
 		break;
+	case PCI_VENDOR_ID_VIA:
+		if (pdev->device == 0x3104 && (pdev->revision & 0xf0) == 0x60) {
+			u8 tmp;
+			/*
+			 * The VT6212 defaults to a 1us EHCI sleep time which
+			 * hogs the bus badly. Setting bit 5 of 0x4B sets the
+			 * sleep time to the EHCI standard 10us.
+			 */
+			pci_read_config_byte(pdev, 0x4b, &tmp);
+			if (tmp & 0x20)
+				break;
+			pci_write_config_byte(pdev, 0x4b, tmp | 0x20);
+		}
+		break;
 	}
 
 	ehci_reset(ehci);

  parent reply	other threads:[~2008-03-18  1:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-04 22:27 ehci-hcd affects hda speed Lev A. Melnikovsky
2008-03-05 16:19 ` Rene Herman
2008-03-05 20:03   ` Alessandro Suardi
2008-03-05 21:03     ` David Brownell
2008-03-06 16:25       ` Alessandro Suardi
2008-03-06 20:10       ` Lev A. Melnikovsky
2008-03-10 10:11         ` Lev A. Melnikovsky
2008-03-15 22:46           ` Lev A. Melnikovsky
2008-03-17 16:15             ` Alessandro Suardi
2008-03-17 21:06             ` David Brownell
     [not found]             ` <47DC596A.4010800@keyaccess.nl>
     [not found]               ` <200803171400.40045.david-b@pacbell.net>
2008-03-17 23:23                 ` Rene Herman
2008-03-17 23:26                   ` Rene Herman
2008-03-18  0:00                   ` David Brownell
2008-03-18  0:24                     ` Lev A. Melnikovsky
2008-03-18  1:27                       ` Rene Herman
2008-03-18  1:45                         ` David Brownell
2008-03-18  1:23                     ` Rene Herman [this message]
2008-03-18  1:55                       ` David Brownell
2008-03-18  3:13                         ` Rene Herman
2008-03-19 23:47                         ` Lev A. Melnikovsky
2008-03-20  0:31                           ` Rene Herman
2008-03-20  5:08                             ` Alessandro Suardi
2008-03-20 11:35                               ` Rene Herman
2008-03-20 21:01                                 ` Alessandro Suardi
2008-04-15 19:56                             ` Lev A. Melnikovsky
2008-04-15 20:02                               ` Oliver Neukum
2008-04-15 20:41                                 ` Lev A. Melnikovsky
2008-04-16  5:38                                   ` Oliver Neukum
2008-04-16 22:23                                     ` Lev A. Melnikovsky
2008-04-17  8:20                                       ` Oliver Neukum
2008-04-15 20:24                               ` Rene Herman
2008-04-15 20:32                               ` Rene Herman
2008-04-15 23:17                               ` David Brownell
2008-04-16 22:44                                 ` Lev A. Melnikovsky
2008-03-18 22:02                       ` Alessandro Suardi
2008-03-18 22:09                         ` Rene Herman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47DF19AD.405@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=alessandro.suardi@gmail.com \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=melnikovsky@mail.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.