i.MX6 on-die temperature sensor

[Warner Losh]

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,
>>> 
>>> 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.

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