Re: [PATCH 00/26] STA2X11 devicetree support for amba/pci

["H. Peter Anvin" <hpa@zytor.com>]

On 08/07/2013 03:16 AM, Alessandro Rubini wrote:
> 
> Some of the problems he found are:
> 
>      * Passing a dtb to the kernel: we use a modified kexec at present
>        because x86 boot loaders can't pass the DT blob, to our knowledge.
> 
>      * Passing correct irq numbers to the AMBA drivers, because PCI MSI
>        irq numbers are dynamically allocated (we solved this by using
>        of_update_property() at runtime). We also had to register a new
>        irq domain for msi irqs, otherwise of_irq_map_one() would complain
>        about irqs lacking a corresponding domain.
> 
>      * Switching to a new gpio driver with devicetree support (we took the
>        Nomadik gpio/pinctrl because our device apparently has more or less
>        the same gpio cell as the Nomadik chip). This requires implementation
>        of writel_relaxed() and IRQF_VALID on x86: we hacked them internally
>        but the patches are not part of this set. We're willing to solve
>        these incompatibilities first, if there's interest.
> 
>      * Writing a suitable dts: at present, a dts only exists for one
>        of the STA2X11 based boards (Intel Northville). This includes a
>        copy of all the physical addresses for the devices, as dts requires
>        that, even if such addresses are automatically assigned by PCI.
>        Clearly, with this approach we kill PCI autodetect: if you plug
>        to a different slot you need a different dts.
> 
> This got us a more or less working kernel on the Northville board
> (where the device is soldered on the motherboard and acts as main chipset).
> The plug-in PCIe board cannot be supported by device tree, as far as
> we know, which in our opinion is a strong downside of device tree in favor
> of the platform data "shit".
> 

OK, so we have a real corner case here... which is a plugin board beyond
which sits a bus normally used by fixed devices.  You are definitely
correct that this is something that stresses current means of
description to the breaking point.

*Note there are some questions below that I would perfectly understand
if you can't talk about publicly, if so, please contact me privately at
my corporate address.*

However, the plugin board is very different from it being the main
chipset, in no small part because you can boot without it.  I think this
is the first time I have ever heard of a chip which can act both as a
system chipset and a plugin card.

The mainboard case is relatively straightforward -- we should use ACPI 5
(preferred for x86) or device tree to describe it.  My understanding
from what you describe so far is that the only existing case is the
Northville which is a mainboard.

For the plugin case, my thinking is that we probably do need a driver of
some kind which at least contains the description of the board, as I
assume one is not present in any kind of firmware on the board itself
(*do any such boards or plans for them actually exist at this point?*)
Ideally that driver should be (primarily?) a data object (an ACPI 5 SSDT
or a DTB file) rather than open coded C.

I believe ACPI 5 unlike device tree should be able to specify the
dynamic properties that you are rightfully concerned with.

Sorry if this feels like a wild goose chase to you.  Some of this
problem domain is not very well handled by the current code, but we
really have to draw a hard line to make sure it doesn't descend into
unmaintainable chaos.

We have similar issues with MinnowBoard and are trying to use that as a
platform to figure out how a lot of these things need to be handled.

	-hpa