Message-Id: <200803171855.44552.david-b@pacbell.net>
Date:	Mon, 17 Mar 2008 17:55:44 -0800
From:	David Brownell <david-b@...bell.net>
To:	Rene Herman <rene.herman@...access.nl>
Cc:	"Lev A. Melnikovsky" <melnikovsky@...l.ru>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: ehci-hcd affects hda speed

On Monday 17 March 2008, Rene Herman wrote:
> 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.

Probably the same one I saw, from that URL.


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

True, and bothersome.  All VIA would have to do is adopt a design
and production methodology different than they've used for many
years now, and this problem wouldn't appear.  ;)

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

No ... see below:


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

... I was wrong about the vt8235 preceding the vt6212 then!


> 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'd take that.  Thing is, someone sent me a vt8235 datasheet
which explicitly says "do not write that register", which
makes the ">= 0x60" test a lose.


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

They could try the "setpci" thing you used ... but even if
that works, I'd really want to avoid writing into registers
where the docs say "do not write".  Unless VIA comes out and
says "just kidding!" ... :)

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

OK, I'll leave this in my mailbox for a few days waiting more
testing results, and if nothing goes wrong I'll send it along
for a post-2.6.25 merge.

Thanks!

- Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists