From owner-svn-src-all@FreeBSD.ORG Mon Dec 9 21:47:50 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94FC967C; Mon, 9 Dec 2013 21:47:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 67F7612F9; Mon, 9 Dec 2013 21:47:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED20EB98F; Mon, 9 Dec 2013 16:47:48 -0500 (EST) From: John Baldwin To: "=?iso-8859-15?q?Jean-S=E9bastien?= =?iso-8859-15?q?_P=E9dron?=" Subject: Re: svn commit: r258930 - head/sys/dev/drm2 Date: Mon, 9 Dec 2013 16:46:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201312041904.rB4J4vbM043709@svn.freebsd.org> <201312051005.23197.jhb@freebsd.org> <52A266CF.90007@FreeBSD.org> In-Reply-To: <52A266CF.90007@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201312091646.27179.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Dec 2013 16:47:49 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:47:50 -0000 On Friday, December 06, 2013 7:07:43 pm Jean-S=E9bastien P=E9dron wrote: > Le 05/12/2013 16:05, John Baldwin a =E9crit : > >>> Eh, vgapci is the right place to read this. The LINK_CAP here is=20 telling > >>> you the width of the slot you are plugged into, not the width of the= =20 card > >>> that is plugged into the slot. > >> > >> I'm sorry, my knowledge of PCI is very limited (still learning) and I > >> don't understand your comment. Could you please expand on it? > > > > [explanation] >=20 > Thank you very much for the explanation! >=20 > > Can you provide pciconf -lc output from your machine >=20 > You'll find it attached. >=20 > > and tell me what you think the function should be returning (i.e. > > are you trying to determine the speed of the slot, or the speed of > > the card?) >=20 > The result of this function is used to initialize the card (ie. it does=20 > more steps if speed is 5.0). The debug message is "enabling PCIE gen 2=20 > link speeds" in this case. I admit I don't know what the code is doing=20 > exactly, so I haven't any expectation :) >=20 > What I see is that now, this part of the initialization is similar to=20 > Linux 3.8 on the same computer: in both OSes, the PCI ID of the bridge=20 > and the linkcap/linkcap2 values are logged, and the PCI ID/values are=20 > matching. Ok, after looking at the original version of this function in Linux, it does read the capabilities from the parent bridge of the slot, not from the card itself, so your change is correct. =2D-=20 John Baldwin