From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: RFC: [PATCH 1/3] Enhance platform support for PCI Date: Thu, 26 Feb 2015 11:05:10 +0000 Message-ID: <1424948710.14641.25.camel@citrix.com> References: <54E71BDE.5020106@caviumnetworks.com> <54E7229C.7000301@linaro.org> <54E72452.3090801@caviumnetworks.com> <54E72688.9010005@linaro.org> <54E729F1.6000804@caviumnetworks.com> <54E73010.2050902@caviumnetworks.com> <1424439941.30924.243.camel@citrix.com> <54E74EA802000078000620B7@mail.emea.novell.com> <1424442385.30924.265.camel@citrix.com> <54E7552F020000780006215A@mail.emea.novell.com> <1424444504.30924.282.camel@citrix.com> <54E75D8702000078000621DD@mail.emea.novell.com> <1424453619.30924.381.camel@citrix.com> <54EAF6390200007800062593@mail.emea.novell.com> <1424695518.27930.74.camel@citrix.com> <54EB42320200007800062871@mail.emea.novell.com> <1424702013.27930.118.camel@citrix.com> <54EB4AFE02000078000628B3@mail.emea.novell.com> <1424703761.27930.140.camel@citrix.com> <54EB54D8020000780006296F@mail.emea.novell.com> <1424706397.27930.178.camel@citrix.com> <54EB61430200007800062AEA@mail.emea.novell.com> <54EEF0F3.4050403@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54EEF0F3.4050403@caviumnetworks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Manish Jaggi Cc: Prasun.kapoor@cavium.com, Vijaya Kumar , Julien Grall , xen-devel@lists.xen.org, "StefanoStabellini(Stefano.Stabellini@citrix.com)" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On Thu, 2015-02-26 at 15:39 +0530, Manish Jaggi wrote: > Have you reached a conclusion? My current thinking on how PCI for Xen on ARM should look is thus: xen/arch/arm/pci.c: New file, containing core PCI infrastructure for ARM. Includes: pci_hostbridge_register(), which registers a host bridge: Registration includes: DT node pointer CFG space address pci_hostbridge_ops function table, which contains e.g. cfg space read/write ops, perhaps other stuff). Function for setting the (segment,bus) for a given host bridge. Lets say pci_hostbridge_setup(), the host bridge must have been previously registered. Looks up the host bridge via CFG space address and maps that to (segment,bus). Functions for looking up host bridges by various keys as needed (cfg base address, DT node, etc) pci_init() function, called from somewhere appropriate in setup.c which calls device_init(node, DEVICE_PCIHOST, NULL) (see gic_init() for the shape of this) Any other common helper functions for managing PCI devices, e.g. for implementing PHYSDEVOP_*, which cannot be made properly common (i.e. shared with x86). xen/drivers/pci/host-*.c (or pci/host/*.c): New files, one per supported PCI controller IP block. Each should use the normal DT_DEVICE infrastructure for probing, i.e.: DT_DEVICE_START(foo, "FOO", DEVICE_PCIHOST) Probe function should call pci_hostbridge_register() for each host bridge which the controller exposes. xen/arch/arm/physdev.c: Implements do_physdev_op handling PHYSDEVOP_*. Includes: New hypercall subop PHYSDEVOP_pci_host_bridge_add: As per 1424703761.27930.140.camel@citrix.com> which calls pci_hostbridge_setup() to map the (segment,bus) to a specific pci_hostbridge_ops (i.e. must have previously been registered with pci_hostbridge_register(), else error). PHYSDEVOP_pci_device_add/remove: Implement existing hypercall interface used by x86 for ARM. This requires that PHYSDEVOP_pci_host_bridge_add has been called for the (segment,bus) which it refers to, otherwise error. Looks up the host bridge and does whatever setup is required plus e.g. calling of pci_add_device(). No doubt various other existing interfaces will need wiring up, e.g. pci_conf_{read,write}* should lookup the host bridge ops struct and call the associated method. I'm sure the above must be incomplete, but I hope the general shape makes sense? Ian.