Date: Sat, 08 Feb 2014 15:50:44 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Steven Lawrance <stl@koffein.net>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: i.MX6 on-die temperature sensor Message-ID: <52F6A6B4.2050806@freebsd.org> In-Reply-To: <1391893231-sup-6174@luwak.koffein.net> References: <1391893231-sup-6174@luwak.koffein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/08/14 15:32, Steven Lawrance wrote: > Hi all, > > a Wandboard turned up on my desk yesterday and I thought I'd get > started with something simple -- the on-chip temperature sensor. > > A patch is attached, but I've got a few questions, mostly about FDTs: > > The driver doesn't need to reserve any resources for itself but rather > refer to two others, anatop and ocotp. How can that relationship be > represented in the FDT? > > How is the sequence of device attachments determined? Just by the > order in the FDT? The current scenario seems quite fragile if that's > the case. > > For the OCOTP (on-chip one-time-programmable memory) side of things, I > just followed the pattern in imx6_anatop.c, which is to provide public > methods for accessing its memory space. But it feels a bit dirty -- I > imagine there could be cases where you would have two similar blocks > and things would fall apart. > > cheers, > This is a really interesting issue. Bus probe order is based first on the pass of the driver (see EARLY_DRIVER_MODULE) and then on the order in the device tree. If you can mark anatop and ocotp as "early", then your immediate issue should go away. More generally, newbus basically doesn't support relationships between devices that don't follow the bus hierarchy. On embedded systems, these are common and tricky to handle. For simple cases, we can get away with multiple passes -- maybe with simple extensions such as being able to return an EAGAIN code for "please come back later once other devices are attached". A simple way to register a device_t (or kobj in general) to a particular handle (probably a phandle_t for OF systems) would also help. More generally, the problem becomes exceedingly complex. The really problematic case is interrupts: it is easy to have situations where the interrupt controller itself is attached via a bus that needs interrupts itself. This is not a hypothetical: PPC macs using Open Firmware have exactly this topology, where the primary interrupt controller is a subunit of a PCI device underneath a few PCI<->PCI bridges. No bus ordering fixes the situation there since a circular dependency exists (to attach, the interrupt controller driver needs to allocate memory from its bus parent, but, to attach, that parent, and its parent, have to allocate interrupts!). For PowerPC, we handle this by having a virtual interrupt configuration layer that allocates interrupts at any time but defers actual configuration until after bus probing. A generalization of that approach might be valuable for other such situations. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52F6A6B4.2050806>