Date: Thu, 14 Feb 2013 08:53:19 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: "freebsd-arch@FreeBSD.org Arch" <freebsd-arch@freebsd.org> Subject: Re: FDT on x86 and for non-fdtbus devices. Message-ID: <129FAAB3-469A-47D5-AA46-1806665ED357@xcllnt.net> In-Reply-To: <alpine.BSF.2.00.1302141031480.65091@fledge.watson.org> References: <03A622DA-EFD4-4984-8FC3-CD8B4832C32E@xcllnt.net> <alpine.BSF.2.00.1302141031480.65091@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 14, 2013, at 2:33 AM, Robert Watson <rwatson@FreeBSD.ORG> wrote:
>=20
> On Wed, 13 Feb 2013, Marcel Moolenaar wrote:
>=20
>> I think one way to state the problem in a generic way is: How can we =
obtain the FDT pnode_t given an arbitrary device_t and use the pnode_t =
to query for properties, etc.
>>=20
>> Are people already doing things like this? Is there an interest in =
being able to do things like this? Are changes to drivers to have them =
query FDT contributable at all or do people think such would be =
"pollution"?
>=20
> Only loosely related, but another thing we'd like to be able to do at =
SRI/Cambridge is merge ROM-discovered FDT configuration data with =
kernel-linked configuration data.
Not necessarily that loosely related. Both our needs can be
addressed if we always construct a "global" FDT by merging
different sources, like firmware, compiled-in and generated
by enumerating PCI, ISA PnP, et al.
My want of using the FDT to fine-tune the behaviour of PCI
devices or describing iic/smb hierarchies when the host
controller isn't rooted in FDT is addressed by virtue of
everything now being rooted in the FDT.
Your need is addressed intrinsically.
The immediate questions that arise from this approach are:
1. How does such a scheme affect boot time?
2. What does it take to change the ACPI interface or the
core PCI code to construct a FDT?
3. When merging, conflicts are to be expected. Is there
a simple answer (discovered has least precedence)?
4. If we nest devices under proximity domains in the FDT,
can we then also solve NUMA related problems generically?
On the one hand it comes across as fairly complex to have
the kernel generate FDT fragments as part of bus enumeration,
then merge all the fragments and finally construct the in-
kernel device driver tree from the merged FDT.
On the other hand, it also "feels" very liberating. We can
put everything we need in the FDT, including how to name an
interface so that it matches the name on the front-panel.
We can override firmware by disabling BARs of PCI devices
in a way to preserve device I/O space.
And... Hot-plug PCI and everything else hot-plug could
potentially be abstracted as "merely" being a matter of
adding (merging) and removing FDT fragments "on the fly".
Again a generic problem that may help us build generic
solutions...
Thoughts?
--=20
Marcel Moolenaar
marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?129FAAB3-469A-47D5-AA46-1806665ED357>