linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liviu Dudau <Liviu.Dudau@arm.com>
To: linux-pci <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>,
	linaro-kernel <linaro-kernel@lists.linaro.org>
Subject: [PATCH] [RFC] Support for creating generic host_bridge from device tree
Date: Mon,  3 Feb 2014 18:33:47 +0000	[thread overview]
Message-ID: <1391452428-22917-1-git-send-email-Liviu.Dudau@arm.com> (raw)

Following the discussion started here [1], I now have a proposal for tackling
generic support for host bridges described via device tree. It is an initial
stab at it, to try to get feedback and suggestions, but it is functional enough
that I have PCI Express for arm64 working on an FPGA using the patch that I am
also publishing that adds support for PCI for that platform.

Looking at the existing architectures that fit the requirements (use of device
tree and PCI) yields the powerpc and microblaze as generic enough to make them
candidates for conversion. I have a tentative patch for microblaze that I can
only compile test it, unfortunately using qemu-microblaze leads to an early
crash in the kernel.

As Bjorn has mentioned in the previous discussion, the idea is to add to
struct pci_host_bridge enough data to be able to reduce the size or remove the
architecture specific pci_controller structure. arm64 support actually manages
to get rid of all the architecture static data and has no pci_controller structure
defined. For host bridge drivers that means a change of API unless architectures
decide to provide a compatibility layer (comments here please).

In order to initialise a host bridge with the new API, the following example
code is sufficient for a _probe() function:

static int myhostbridge_probe(struct platform_device *pdev)
{
	int err;
	struct device_node *dev;
	struct pci_host_bridge *bridge;
	struct resource bus_range;
	struct myhostbridge_port *pp;
	LIST_HEAD(resources);

	dev = pdev->dev.of_node;

	if (!of_device_is_available(dev)) {
		pr_warn("%s: disabled\n", dev->full_name);
		return -ENODEV;
	}

	pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
	if (!pp)
		return -ENOMEM;

	err = of_pci_parse_bus_range(dev, &bus_range);
	if (err) {
		bus_range.start = 0;
		bus_range.end = 255;
		bus_range.flags = IORESOURCE_BUS;
	}
	pci_add_resource(&resources, &bus_range);

	bridge = pci_host_bridge_of_init(&pdev->dev, 0, &myhostbridge_ops, pp, &resources);
	if (!bridge) {
		err = -EINVAL;
		goto bridge_init_fail;
	}

	err = myhostbridge_setup(bridge->bus);
	if (err)
		goto bridge_init_fail;

	/*
	 * Add flags here, this is just an example
	 */
	pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
	pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);

	bus_range.end = pci_scan_child_bus(bridge->bus);
	pci_bus_update_busn_res_end(bridge->bus, bus_range.end);

	pci_assign_unassigned_bus_resources(bridge->bus);

	pci_bus_add_devices(bridge->bus);

	return 0;

bridge_init_fail:
	kfree(pp);
	pci_free_resource_list(&resources);
	return err;
}

Best regards,
Liviu Dudau

[1] http://thread.gmane.org/gmane.linux.kernel.pci/25946

Liviu Dudau (1):
  pci: Add support for creating a generic host_bridge from device tree

 drivers/pci/host-bridge.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/probe.c       | 11 ++++++
 include/linux/pci.h       | 14 ++++++++
 3 files changed, 117 insertions(+)

-- 
1.8.5.3


             reply	other threads:[~2014-02-03 18:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 18:33 Liviu Dudau [this message]
2014-02-03 18:33 ` [PATCH] pci: Add support for creating a generic host_bridge from device tree Liviu Dudau
2014-02-03 18:46   ` Arnd Bergmann
2014-02-03 19:06     ` Liviu Dudau
2014-02-03 19:31       ` Arnd Bergmann
2014-02-03 22:17         ` Liviu Dudau
2014-02-04 10:09           ` Arnd Bergmann
2014-02-04 12:08             ` Liviu Dudau
2014-02-04 15:56               ` Arnd Bergmann
2014-02-05 22:26     ` Tanmay Inamdar
2014-02-06 10:18       ` Liviu Dudau
2014-02-08  0:21         ` Tanmay Inamdar
2014-02-08 14:22           ` Liviu Dudau
2014-02-09 20:22             ` Arnd Bergmann
2014-02-10 18:06             ` Tanmay Inamdar
2014-02-13  8:10         ` Jingoo Han
2014-02-13  8:18           ` Jingoo Han
2014-02-13  8:36           ` Tanmay Inamdar
2014-02-13  8:57             ` Jingoo Han
2014-02-13 11:27               ` Arnd Bergmann
2014-02-13 11:53                 ` Russell King - ARM Linux
2014-02-13 12:15                   ` Arnd Bergmann
2014-02-13 12:20               ` Liviu Dudau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1391452428-22917-1-git-send-email-Liviu.Dudau@arm.com \
    --to=liviu.dudau@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).