From owner-freebsd-arm@freebsd.org Tue Aug 16 12:36:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4611BBBBED3; Tue, 16 Aug 2016 12:36:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 226C21816; Tue, 16 Aug 2016 12:36:38 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([172.58.16.198]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u7GCaVaW020958 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Aug 2016 05:36:34 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Andrew Turner References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <579CD355.1050203@FreeBSD.org> <460fa0b3-ddb7-6247-2412-3d75a589d5e7@freebsd.org> <579CF7C8.1040302@FreeBSD.org> <24107713-6d50-c21d-ccf1-7dbdb36cc484@freebsd.org> <579E1BE2.7020500@FreeBSD.org> <7f053bb8-ab03-e46c-1c72-d757348e4e54@freebsd.org> <57A09F34.4050400@FreeBSD.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> <20160816103746.6fca94e4@zapp> Cc: Michal Meloun , "freebsd-arm@freebsd.org" , Svatopluk Kraus , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <2c97041d-5c79-432d-caf2-7744131a8524@freebsd.org> Date: Tue, 16 Aug 2016 05:36:28 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160816103746.6fca94e4@zapp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZlNilkbwiaf7BTR7+ESbTxqK9Xy/cV2lle+VlkTWDx4ii3d+6ryxZCURlRzefPs0YVLWT/Phvb5919bslekeqFtpZsgMNH2bM= X-Sonic-ID: C;in6iD65j5hGAGqDx2xNB0g== M;Ol4bEa5j5hGAGqDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:36:39 -0000 On 08/16/16 02:37, Andrew Turner wrote: > On Fri, 12 Aug 2016 08:31:06 -0700 > Nathan Whitehorn wrote: >> One other non-urgent question about PCI code: >> >> There's a new function ofw_bus_msimap() that does not seem to >> implement any particular part of any real binding standard. There's >> a .txt file in the device-tree repo, but many (most?, all?) PCI >> bridges don't seem to implement MSI that way. This is out-of-scope >> for the immediate discussion, but it would be good to fix later. If >> there are indeed only a handful of bridges that do MSI that way, it >> should probably be moved into the PCI bridge drivers that do use it. > The ofw_bus_msimap() implements the standard FDT MSI properties to > find the needed MSI/MSI-X controller. See [1] for the binding document. Yes, but ThunderX seems to be the only host bridge that actually implements those bindings. I've never run into another, certainly, and there don't seem to be any others in the tree. >> Similarly, dev/pci/pci_host_generic.c isn't actually generic and is >> instead a driver for some particular ARM bridges. It should be moved >> at some point under sys/arm. Most of the code in it also duplicates >> dev/ofw/ofwpci.c (but with some added bugs in handling the "ranges" >> property). > I don't see why. There is nothing ARM specific in it. I also have > patches to use it with ACPI as the existing driver makes assumptions > about PCI that may not be true on all platforms. There's an "arm,gem5_pcie" in there that is certainly suggestive of ARM-ness. At any rate, much like the MSI bits, I could imagine multiple controllers implementing the interface defined in this driver but there do not seem, at present, to be any. Most of the code is indeed generic but duplicates ofwpci. That code should be replaced through inheritance with the ofwpci.c equivalents; the only remaining bits are MSI allocation and config space access, which seem to be specific to a few kinds of ARM hardware. -Nathan > > Andrew > > [1] > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/pci-msi.txt >