Re: [PATCH v10 00/10] Support for creating generic PCI host bridges from DT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 9/12/2014 4:30 AM, Liviu Dudau wrote:
On Fri, Sep 12, 2014 at 09:25:13AM +0100, Suravee Suthikulpanit wrote:
On 9/8/2014 8:54 AM, Liviu Dudau wrote:
This is my version 10 of the attempt at adding support for generic PCI host
bridge controllers that make use of device tree information to
configure themselves. This version reverses v9's attempt to create one function
to drive the whole process of extracting the host bridge ranges, setup the
host bridge driver and then scan the root bus behind the host bridge. While it
would've been quite user friendly, I agree that it would've caused a lot of pain
in the future.

I would like to get ACKs for the remaining patches as I would like to integrate
this into -next in the following week.

This version marks an implementation break with the previous versions as
of_create_pci_host_bridge() is now gone. It gets replaced by
of_pci_get_host_bridge_resources() that only parses the DT and extracts the
relevant ranges and converts them to resources. The updated host bridge drivers
will have to follow the guidelines in this example code:

static int foohb_probe(struct platform_device *pdev)
{
	struct device_node *dn = pdev->dev.of_node;
	struct foohb_drv *drv;
	resource_size_t io_base = 0;  /* phys address for start of IO */
	struct pci_bus *bus;
	int err = 0;
	LIST_HEAD(res);

	.....
	err = of_pci_get_host_bridge_resources(dn, 0, 255, &res, &io_base);
	if (err)
		goto err_handling;
	err = foohb_setup(drv, ...., &res, &io_base);
	if (err)
		goto err_handling;

Hi Suravee,


My understanding is that the "foohb_setup" above is supposed to be equivalent
to the "int (*setup)(struct pci_host_bridge *, resource_size_t)" in V9 that was
passed in as an argument of "of_create_pci_hot_bridge()".

Correct. Parameters are probably different, but it is internal to your driver so
you can do whatever you want there.


The problem I have is I need an intermediate step between "pci_create_root_bus()"
and "pci_scan_child_bus()" in order to update the information such as the "pci_bus->msi"
before this is propagate down to the child bus during the "pci_scan_child_bus"
which is also called in the pci_scan_root_bus() function.

How did that work with my v9 patchset? How does it work for other MSI-aware platforms?
Are they not using pci_scan_child_bus()?

In the of_create_pci_host_bridge of V9, you call the setup function between "pci_create_root_bus()"
and "pci_scan_child_bus()". At that point, I can update the "root_bus->msi" to point to my
"struct msi_chip" which was created during GICv2m initialization
(Please see http://marc.info/?l=linux-kernel&m=141034053331632&w=2).
Then, when a child bus is created, it propagate this msi_chip pointer from the parent bus.

Suravee


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux