Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Aug 2016 05:36:28 -0700
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Andrew Turner <andrew@fubar.geek.nz>
Cc:        Michal Meloun <mmel@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Svatopluk Kraus <skra@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: INTRNG (Was: svn commit: r301453....)
Message-ID:  <2c97041d-5c79-432d-caf2-7744131a8524@freebsd.org>
In-Reply-To: <20160816103746.6fca94e4@zapp>
References:  <201606051620.u55GKD5S066398@repo.freebsd.org> <57976867.6080705@FreeBSD.org> <f2edac8f-2859-cd98-754e-881e2b2d1e63@freebsd.org> <5798E104.5020104@FreeBSD.org> <a5d43044-1733-6cc7-2e99-e85b60b0fcf3@freebsd.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <eb603349-eb88-866d-7a26-9e026518fd39@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> <cefdfaab-a95f-2a92-89bd-3d0cef2a75ab@freebsd.org> <57A09F34.4050400@FreeBSD.org> <ad1e6337-468e-f35d-7454-444a561cb103@freebsd.org> <57A30B72.7070809@FreeBSD.org> <1946069a-d0f9-2c19-80a5-0b490682574b@freebsd.org> <57A5F480.20309@FreeBSD.org> <d438c970-3bd1-e81a-e56d-3632fa85b921@freebsd.org> <20160816103746.6fca94e4@zapp>

next in thread | previous in thread | raw e-mail | index | archive | help


On 08/16/16 02:37, Andrew Turner wrote:
> On Fri, 12 Aug 2016 08:31:06 -0700
> Nathan Whitehorn <nwhitehorn@freebsd.org> 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
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2c97041d-5c79-432d-caf2-7744131a8524>