Date: Sat, 08 Feb 2014 17:06:09 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-arm@freebsd.org Subject: Re: i.MX6 on-die temperature sensor Message-ID: <52F6B861.8010908@freebsd.org> In-Reply-To: <1391897489.1196.60.camel@revolution.hippie.lan> References: <1391893231-sup-6174@luwak.koffein.net> <1391897489.1196.60.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/08/14 16:11, Ian Lepore wrote: > On Sat, 2014-02-08 at 22:32 +0100, 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, >> > Yeah, the devices are attached in the order listed in the fdt, which is > pretty horrible and affects us we get fdt data mostly from linux (the > source of standard fdt data for boards), and it isn't driven by the > order of things in the data. > This isn't true. They are only attached in FDT order if your driver does not specify an alternative. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52F6B861.8010908>