Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753139AbbHERMT (ORCPT ); Wed, 5 Aug 2015 13:12:19 -0400 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:32000 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752050AbbHERMR convert rfc822-to-8bit (ORCPT ); Wed, 5 Aug 2015 13:12:17 -0400 From: Varun Sethi To: Mark Rutland , "devicetree@vger.kernel.org" CC: "lorenzo.pieralisi@arm.com" , "arnd@arndb.de" , "marc.zyngier@arm.com" , "will.deacon@arm.com" , "linux-kernel@vger.kernel.org" , "ddaney@caviumnetworks.com" , "iommu@lists.linux-foundation.org" , "tirumalesh.chalamarla@caviumnetworks.com" , "laurent.pinchart@ideasonboard.com" , "thunder.leizhen@huawei.com" , "treding@nvidia.com" , "linux-arm-kernel@lists.infradead.org" , "majun258@huawei.com" , Stuart Yoder Subject: RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings Thread-Topic: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings Thread-Index: AQHQxWgdXTLkJz5ZsEWnWOa6RYhTe539hwvg Date: Wed, 5 Aug 2015 16:39:33 +0000 Message-ID: References: <1437670365-20704-1-git-send-email-mark.rutland@arm.com> <1437670365-20704-3-git-send-email-mark.rutland@arm.com> In-Reply-To: <1437670365-20704-3-git-send-email-mark.rutland@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Varun.Sethi@freescale.com; x-originating-ip: [122.177.198.131] x-microsoft-exchange-diagnostics: 1;CY1PR0301MB0746;5:tFuVhddSLbxoq6SrBtz+cIeuO5W1V7v0BdX/lnBDbyDkyDBwN2m5ipS9u/LzEYDMotWiJRJGSKg/EHYF74F6SIcGO22eeCF+8CaA8potbckWzFgrXj9IUSvbEYwbS5IwJakxNSRhkjqSSAgl8S1Xdg==;24:1Pgn8xkVEmbg0ZXpBcboSF4kRUwKvhGTkfXZM9Tra+iS+Q8yWoU7ZoCw2Lko6kyWoj2G1xWUUJyKgKOQi5pAOLgNJlEBxLjDWBu2WGsa88o=;20:RVKmFCl8uudi37xXLtzAZhAvNIEfywizxT44+EC4/xueZZwy3eLOMA0IUpdiNspc+tEWFLhDbAyDvKvyS4s/IA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0746; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:CY1PR0301MB0746;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0746; x-forefront-prvs: 06592CCE58 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(13464003)(199003)(51914003)(377454003)(189002)(106356001)(77096005)(92566002)(87936001)(15975445007)(122556002)(2656002)(19580395003)(102836002)(64706001)(5001960100002)(189998001)(40100003)(107886002)(2900100001)(19580405001)(86362001)(5002640100001)(74316001)(2950100001)(2501003)(4001540100001)(5001770100001)(81156007)(101416001)(46102003)(5001920100001)(5001860100001)(76576001)(10400500002)(97736004)(66066001)(5001830100001)(33656002)(106116001)(105586002)(77156002)(5003600100002)(68736005)(50986999)(99286002)(62966003)(54356999)(76176999)(4001430100001)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0301MB0746;H:BN1PR0301MB0627.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2015 16:39:33.7547 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0746 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8628 Lines: 290 Hi Mark Thanks for the patch. Please find my comment inline. Regards Varun > -----Original Message----- > From: iommu-bounces@lists.linux-foundation.org [mailto:iommu- > bounces@lists.linux-foundation.org] On Behalf Of Mark Rutland > Sent: Thursday, July 23, 2015 10:23 PM > To: devicetree@vger.kernel.org > Cc: Mark Rutland; lorenzo.pieralisi@arm.com; arnd@arndb.de; > marc.zyngier@arm.com; will.deacon@arm.com; linux- > kernel@vger.kernel.org; ddaney@caviumnetworks.com; iommu@lists.linux- > foundation.org; tirumalesh.chalamarla@caviumnetworks.com; > laurent.pinchart@ideasonboard.com; thunder.leizhen@huawei.com; > treding@nvidia.com; linux-arm-kernel@lists.infradead.org; > majun258@huawei.com > Subject: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings > > Currently msi-parent is used by a few bindings to describe the relationship > between a PCI root complex and a single MSI controller, but this property > does not have a generic binding document. > > Additionally, msi-parent is insufficient to describe more complex > relationships between MSI controllers and devices under a root complex, > where devices may be able to target multiple MSI controllers, or where MSI > controllers use (non-probeable) sideband information to distinguish devices. > > This patch adds a generic binding for mapping PCI devices to MSI controllers. > This document covers msi-parent, and a new msi-map property (specific to > PCI*) which may be used to map devices (identified by their Requester ID) to > sideband data for each MSI controller that they may target. > > Signed-off-by: Mark Rutland > --- > Documentation/devicetree/bindings/pci/pci-msi.txt | 220 > ++++++++++++++++++++++ > 1 file changed, 220 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt > > diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt > b/Documentation/devicetree/bindings/pci/pci-msi.txt > new file mode 100644 > index 0000000..9b3cc81 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt > @@ -0,0 +1,220 @@ > +This document describes the generic device tree binding for describing > +the relationship between PCI devices and MSI controllers. > + > +Each PCI device under a root complex is uniquely identified by its > +Requester ID (AKA RID). A Requester ID is a triplet of a Bus number, > +Device number, and Function number. > + > +For the purpose of this document, when treated as a numeric value, a > +RID is formatted such that: > + > +* Bits [15:8] are the Bus number. > +* Bits [7:3] are the Device number. > +* Bits [2:0] are the Function number. > +* Any other bits required for padding must be zero. > + > +MSIs may be distinguished in part through the use of sideband data > +accompanying writes. In the case of PCI devices, this sideband data may > +be derived from the Requester ID. A mechanism is required to associate > +a device with both the MSI controllers it can address, and the sideband > +data that will be associated with its writes to those controllers. > + > +For generic MSI bindings, see > +Documentation/devicetree/bindings/interrupt-controller/msi.txt. > + > + > +PCI root complex > +================ > + > +Optional properties > +------------------- > + > +- msi-map: Maps a Requester ID to an MSI controller and associated > + msi-specifier data. The property is an arbitrary number of tuples of > + (rid-base,msi-controller,msi-base,length), where: [varun] How would we account for hot plug PCI devices and SR-IOV use cases, with the rid base and length? How do we take in to account for a PCIe bridge, while setting up the requestor ID base and length? > + > + * rid-base is a single cell describing the first RID matched by the entry. > + > + * msi-controller is a single phandle to an MSI controller > + > + * msi-base is an msi-specifier describing the msi-specifier produced for the > + first RID matched by the entry. > + > + * length is a single cell describing how many consecutive RIDs are matched > + following the rid-base. > + > + Any RID r in the interval [rid-base, rid-base + length) is associated > + with the listed msi-controller, with the msi-specifier (r - rid-base + msi- > base). > + > +- msi-map-mask: A mask to be applied to each Requester ID prior to > +being mapped > + to an msi-specifier per the msi-map property. > + [varun] Can you please elaborate on a use case, where this would help. > +- msi-parent: Describes the MSI parent of the root complex itself. > +Where > + the root complex and MSI controller do not pass sideband data with > +MSI > + writes, this property may be used to describe the MSI controller(s) > + used by PCI devices under the root complex, if defined as such in the > + binding for the root complex. > + > + > +Example (1) > +=========== > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + msi: msi-controller@a { > + reg = <0xa 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + pci: pci@f { > + reg = <0xf 0x1>; > + compatible = "vendor,pcie-root-complex"; > + device_type = "pci"; > + > + /* > + * The sideband data provided to the MSI controller is > + * the RID, identity-mapped. > + */ > + msi-map = <0x0 &msi_a 0x0 0x10000>, > + }; > +}; > + > + > +Example (2) > +=========== > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + msi: msi-controller@a { > + reg = <0xa 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + pci: pci@f { > + reg = <0xf 0x1>; > + compatible = "vendor,pcie-root-complex"; > + device_type = "pci"; > + > + /* > + * The sideband data provided to the MSI controller is > + * the RID, masked to only the device and function bits. > + */ > + msi-map = <0x0 &msi_a 0x0 0x100>, > + msi-map-mask = <0xff> > + }; > +}; > + > + > +Example (3) > +=========== > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + msi: msi-controller@a { > + reg = <0xa 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + pci: pci@f { > + reg = <0xf 0x1>; > + compatible = "vendor,pcie-root-complex"; > + device_type = "pci"; > + > + /* > + * The sideband data provided to the MSI controller is > + * the RID, but the high bit of the bus number is > + * ignored. > + */ > + msi-map = <0x0000 &msi 0x0000 0x8000>, > + <0x8000 &msi 0x0000 0x8000>; > + }; > +}; > + > + > +Example (4) > +=========== > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + msi: msi-controller@a { > + reg = <0xa 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + pci: pci@f { > + reg = <0xf 0x1>; > + compatible = "vendor,pcie-root-complex"; > + device_type = "pci"; > + > + /* > + * The sideband data provided to the MSI controller is > + * the RID, but the high bit of the bus number is > + * negated. > + */ > + msi-map = <0x0000 &msi 0x8000 0x8000>, > + <0x8000 &msi 0x0000 0x8000>; > + }; > +}; > + > + > +Example (5) > +=========== > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + msi_a: msi-controller@a { > + reg = <0xa 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + msi_b: msi-controller@b { > + reg = <0xb 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + msi_c: msi-controller@c { > + reg = <0xc 0x1>; > + compatible = "vendor,some-controller"; > + msi-controller; > + #msi-cells = <1>; > + }; > + > + pci: pci@c { > + reg = <0xf 0x1>; > + compatible = "vendor,pcie-root-complex"; > + device_type = "pci"; > + > + /* > + * The sideband data provided to MSI controller a is the > + * RID, but the high bit of the bus number is negated. > + * The sideband data provided to MSI controller b is the > + * RID, identity-mapped. > + * MSI controller c is not addressable. > + */ > + msi-map = <0x0000 &msi_a 0x8000 0x08000>, > + <0x8000 &msi_a 0x0000 0x08000>, > + <0x0000 &msi_b 0x0000 0x10000>; > + }; > +}; > -- > 1.9.1 > > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/