Date: Thu, 21 Feb 2019 10:22:40 -0800 From: Enji Cooper <yaneurabeya@gmail.com> To: Alexander Motin <mav@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344437 - head/sys/dev/ntb/ntb_hw Message-ID: <B2A09670-6C17-479C-A518-04DF44921055@gmail.com> In-Reply-To: <54cb17e7-9b4a-e779-22b6-0bf317bd86ca@FreeBSD.org> References: <201902211410.x1LEAEa2042271@repo.freebsd.org> <8FC17E30-1360-44CE-9284-286B6282C244@gmail.com> <54cb17e7-9b4a-e779-22b6-0bf317bd86ca@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 21, 2019, at 10:19 AM, Alexander Motin <mav@FreeBSD.org> wrote: >=20 > On 21.02.2019 13:13, Enji Cooper wrote: >>=20 >>> On Feb 21, 2019, at 6:10 AM, Alexander Motin <mav@FreeBSD.org> = wrote: >>>=20 >>> Author: mav >>> Date: Thu Feb 21 14:10:14 2019 >>> New Revision: 344437 >>> URL: https://svnweb.freebsd.org/changeset/base/344437 >>>=20 >>> Log: >>> Allow I/OAT of present Xeon E5/E7 to work thorugh PLX NTB. >>>=20 >>> Its a hack, we can't know/list all DMA engines, but this covers all >>> I/OAT of Xeon E5/E7 at least from Sandy Bridge till Skylake I saw. >>>=20 >>> MFC after: 1 week >>> Sponsored by: iXsystems, Inc. >>>=20 >>> Modified: >>> head/sys/dev/ntb/ntb_hw/ntb_hw_plx.c >>>=20 >>> Modified: head/sys/dev/ntb/ntb_hw/ntb_hw_plx.c >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> --- head/sys/dev/ntb/ntb_hw/ntb_hw_plx.c Thu Feb 21 12:13:27 2019 = (r344436) >>> +++ head/sys/dev/ntb/ntb_hw/ntb_hw_plx.c Thu Feb 21 14:10:14 2019 = (r344437) >>> @@ -202,16 +202,24 @@ ntb_plx_init(device_t dev) >>> if (sc->alut) >>> PNTX_WRITE(sc, 0xc94, 0); >>>=20 >>> - /* Enable Link Interface LUT entries 0/1 for peer 0/1. = */ >>> - PNTX_WRITE(sc, 0xdb4, 0x00090001); >>> + /* Enable all Link Interface LUT entries for peer. */ >>> + for (i =3D 0; i < 32; i +=3D 2) { >>=20 >> Is `32` written down in the NTB spec somewhere? Should it be a = #define, or should it be programmatically adjusted based on the CPU? >=20 > It is a property of the hardware, it has 32 LUT entries. Cool! I was thinking that this is probably a number that can change in = the future, as processor designs evolve. > #define would be good indeed, but the code is already full of other = numeric constants. Yes, but it would make the code more readable/easier to reason through. = That=E2=80=99s where my concern is coming from. Also, thank you very much for working on this :). Cheers! -Enji=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2A09670-6C17-479C-A518-04DF44921055>