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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
