Date: Sat, 8 Feb 2014 17:04:12 -0700 From: Warner Losh <imp@bsdimp.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: i.MX6 on-die temperature sensor Message-ID: <A267E974-3FAC-4BAA-A085-E4456D871E77@bsdimp.com> In-Reply-To: <52F6B861.8010908@freebsd.org> References: <1391893231-sup-6174@luwak.koffein.net> <1391897489.1196.60.camel@revolution.hippie.lan> <52F6B861.8010908@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 8, 2014, at 4:06 PM, Nathan Whitehorn wrote: > On 02/08/14 16:11, Ian Lepore wrote: >> On Sat, 2014-02-08 at 22:32 +0100, Steven Lawrance wrote: >>> Hi all, >>>=20 >>> a Wandboard turned up on my desk yesterday and I thought I'd get >>> started with something simple -- the on-chip temperature sensor. >>>=20 >>> A patch is attached, but I've got a few questions, mostly about = FDTs: >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> cheers, >>>=20 >> 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. >>=20 >=20 > This isn't true. They are only attached in FDT order if your driver = does not specify an alternative. Many of these issues, although not the really complex one Nathan refers = to, I think, are solved by just deferring using the resources that = belong to other devices until you know they've all been probed. We have = a convenient place to do this which we use to enumerate usb bus = topology, known SD cards, known sata drives, etc. config_intrhook(). I = plan on using this to attach devices to the gpiobus after we know all = the gpio nodes in the tree... As for how to refer to other nodes, the clean way is to have a property = in your device node that refers to the other nodes, and we can lookup = the device_t associated with the phandle_t in the property in the FDT = tree. But I'm not sure we have that yet in the tree. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A267E974-3FAC-4BAA-A085-E4456D871E77>